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FOREWORD 


This  report  deals  with  the  activities,  findings, 
conclusions,  and  recomnendations  of  the  Logical  Layer  Initiation 
Task  Group,  one  of  two  tasks  groups  comprising  the  PDES 
Initiation  effort.  The  PDES  initiation  effort  is  a  proof  of 
concept  effort  with  a  subordinate  purpose  of  producing  content 
potentially  suitedale  for  PDES  Version  1.0.  The  primary  goal  of 
the  Logical  Layer  Initiation  Task  Group  was  to  formulate  and  test 
a  methodology  for  developing  the  PDES  specification  along  the 
lines  advocated  in  the  Second  PDES  Report.  The  Task  Group  was 
also  charged  with  making  a  final  report  detailing  its  "lessons 
learned"  and  its  recommendations.  This  report  addresses  that 
charge . 

The  Logical  Layer  Initiation  Task  Group  was  chaired  by  J.  C. 
Kelly  of  Sandia  National  Ledsoratories .  John  Zimmermeui  of  the 
Bendix  Kansas  City  Division  of  Allied  Corporation,  and  Doug 
Schenck  of  McDonnell  Douglas  Aerospace  Information  Services 
Company  formed  the  technical  core  within  the  Logical  Layer 
itself.  In  terms  of  the  declared  content  deliverables  of  the 
project,  Zimmerman  developed  the  "qualified"  NIAM  information 
models  of  the  application  areas  and  the  global  NIAM  information 
model  of  the  Logical  Layer.  Schenck  developed  the  Data 
Specification  language  and  the  expression  of  the  global  models  in 
that  language. 

Many  other  people  contributed  to  the  goals  of  the  Task  Group 
work  by  participating  in  the  development  of  application  area 
information  models  which  were  then  used  to  exercise  the 
methodology.  The  primary  contributors  to  the  development  of 
these  models  and  their  sponsoring  companies  are  nzuned  in  Figures 
1-3  and  1-5  in  Section  1.4.  Appendix  A  contains  valueUsle 
retrospective  comments  on  the  experience  of  the  initiation  effort 
by  the  modelers  of  three  application  areas  and  one  resource  area. 

Of  all  the  contributors  to  the  Task  Group  work,  John 
Zimmerman  deserves  special  mention.  He  has  worked  longer  and 
harder  than  anyone  else  associated  with  the  project,  and  has  had 
the  greatest  technical  impact.  He  defined  the  methodology  and 
provided  the  information  modeling  expertise  to  carry  it  out.  He 
liased  with  the  various  application  layer  groups,  assimilated 
their  models,  and  performed  the  crucial  integration  task  yielding 
the  global  models  supporting  all  the  applications.  He  is  the 
primary  technical  contributor  to  this  report.  In  short,  he  has 
been  the  one  with  whom  the  technical  buck  has  stopped  most  often 
during  this  project. 

The  Logical  Layer  initiation  effort  formally  began  in 
January,  1985  with  a  meeting  at  Boeing.  The  effort  will  end  with 
the  publication  of  this  report.  The  existence  of  the  Task  Group 
was  publicized,  and  a  preliminary  statement  of  purpose  was  given, 


in  the  General  Assembly  at  the  quarterly  meeting  of  the  IGES 
Committee  in  Pomona  in  February,  1985.  It  was  announced  that 
membership  in  the  Task  Group  was  open  to  any  individual  who  could 
commit  to  attending  a  rather  intensive  schedule  of  working 
meetings  and  to  significant  assignments  to  be  completed  between 
meetings.  The  sense  of  urgency  surrounding  the  project,  and,  for 
that  matter,  surrounding  the  entire  initiation  effort,  derives 
from  a  commitment  to  develop  a  single  worldwide  standard  for 
product  data  exchange  within  the  ISO  TC184/SC4  community  as  soon 
as  possible.  (TC184  is  Industrial  Automation  Systems;  SC4  is 
External  Representation  Of  Product  Model  Data;  STEP,  the  eventual 
worldwide  standard,  is  Standard  For  The  Trzmsfer  And  Exchange  Of 
Product  Model  Data.)  The  PDES  Project  has  been  designated  as  the 
mechanism  by  which  the  United  States  will  contribute  to  the  STEP 
effort. 

Since  January,  1985,  scheduled  Logical  Layer  Initiation 
meetings  have  been  held  as  follows: 

Seattle  -  Working  Meeting  -  January,  1985 
Pomona  -  Quarterly  IGES  Meeting  -  February,  1985 
Cincinnati  -  Working  Meeting  -  February,  1985 
Kansas  City  -  Working  Meeting  -  March,  1985 
Atlanta  -  Quarterly  IGES  Meeting  -  April,  1985 
St.  Louis  -  Working  Meeting  -  May,  1985 
Albuquerque  >  Working  Meeting  -  Jtme,  1985 
Madison  -  Quarterly  IGES  Meeting  -  July,  1985 
Los  Angeles  -  Working  Meeting  -  September,  1985 
Knoxville  -  Quarterly  IGES  Meeting  -  October,  1985 
Kansas  City  -  Working  Meeting  -  November,  1985 
San  Diego  -  Quarterly  IGES  Meeting  -  January,  1986 
Albuquerque  -  Working  Meeting  -  February,  1986 

In  addition,  other,  more  informal,  meetings  were  held. 

These  include,  for  exeunple,  liason  meetings  between  Zimmerman  and 
people  from  the  application  areas,  and  meetings  concerned  with 
this  report.  And,  it  would  be  difficult  to  estimate  the  number 
of  lengthy  telephone  conversations  held  in  conjunction  with  the 
project,  but  the  number  is  assuredly  quite  high. 

Meetings  associated  with  the  regular  quarterly  IGES  meetings 
amounted  to  organized  progress  reports  to  a  group  that  has  since 
seen  some  stabilization  and  in  fact  now  forms  the  Logical  Layer 
Committee.  Several  people  with  consideradsle  experience  in 
information  modeling  and  logical  datedsase  design  have  been 
attracted  to  this  group.  Detailed  minutes  were  published 
following  each  quarterly  IGES  meeting,  and  these  were  supplied  to 
the  ISO  Working  Group  TC184/SC4/WG1  as  well. 

The  work  in  the  presentation  area  of  Richard  C.  Winfrey  of 
Digital  Equipment  Corporation  was  used  as  a  basis  for 
establishing  communication  with  the  ANSI  X3H3  Committee 


responsible  for  the  development  of  the  PHIGS  graphics  standard. 
It  is  believed  that  this  type  of  coordination  between  the 
ZGES/PDES  Committee  and  other  standards  development  groups  for 
the  purpose  of  minimizing  duplication  will  be  commonplace  in  the 
future . 


A  talk  on  PDES  in  general#  and  the  initiation  effort  in 
particular#  was  developed  and  presented  at  the  Federal  Computer 
Conference  in  Washington  in  September,  1985#  at  the  PDDI  end-of- 
contract  briefing  in  St.  Louis  in  September#  1985#  and  at  the  SME 
CIMTECH  conference  in  Boston  in  March#  1986.  A  paper  was 
developed  along  the  same  lines  and  was  published  in  Manufacturing 
Productivity  FRONTIERS#  a  pxiblication  of  the  IIT  Research 
Institute#  and  in  the  CIMTECH  conference  proceedings.  The  paper 
is  included  at  the  end  of  this  report  as  Appendix  E. 


This  report  has  been  written  with  the  members  of  the  IGES 
Committee  in  mind.  The  extensive  set  of  Appendices  indicates 
that  we  feel  the  report  has  an  archival  function  to  perform.  An 
effort  has  been  made  to  keep  "gory  details"  in  the  appendices. 

I  believe  that  the  Logical  Layer  Initiation  Task  Group  has 
performed  as  needed  in  a  proof  of  concept  effort.  I  say  this  in 
spite  of  the  fact  that#  because  of  time  and  manpower  constraints, 
we  have  had  to  cut  short  our  efforts  in  some  areas#  and  have  had 
to  leave  open  some  issues  that  have  been  raised.  However#  we  did 
define  a  project  along  the  lines  of  the  Second  PDES  Report  and 
carry  it  out.  We  did  define  a  methodology#  we  have  refined  it  in 
light  of  what  we  consider  to  be  authentic  experience#  and  we  are 
able  to  recoxnmend  it.  We  did  gain  some  experience  and  we  do  have 
some  lessons  learned  to  relate  and  some  recommendations  to  give. 
And#  we  did  cause  some  of  the  standing  IGES  committees  to 
mobilize  and  gain  some  experience  with  information  modeling.  We 
believe  these  are  all  positive  contributions  toward  the 
development  of  PDES  Version  1.0. 

Dixie  Chavez  of  Sandia  National  Ledsoratories  and  Will 
Williams  of  Bendix#  Kansas  City  Division  deserve  special  thanks 
for  their  help  in  preparing  this  report.  Our  wives  and  families 
deserve  our  thanks  for  helping  us  live  through  the  initiation 
experience#  and  we  congratulate  them  for  living  through  it 
themselves . 


I  speak  for  the  entire  Task  Group  when  I  say  we  are  proud  to 
present  the  results  of  our  work  to  the  IGES/PDES  Committee.  We 
look  forward  to  continuing  participation  in  the  development  of 
PDES#  and  we  wish  Doug  Schenck  great  success  in  his  new  role  of 
Logical  Layer  Chairman. 


J.  C.  Kelly#  Chairman 

PDES  Logical  Layer  Initiation  Task  Group 


Section  One 


1.  Introduction 

1.1  The  Mission  Of  The  PDES  Initiation  Effort 

The  PDES  initiation  effort  is  a  limited  term  proof  of 
concept  effort.  The  intent  is  to  gain  initial  experience  in 
developing  an  exchange  specification  for  product  data  in 
accordance  with  what  was  proposed  in  the  Second  PDES  Report  (See 
Reference  1) .  The  emphasis  is  on  establishing  a  development 
methodology  and  on  reporting  back  lessons  learned  and 
recommendations.  A  lesser  emphasis  is  on  developing  actual 
content  for  longer  term  PDES  work;  however,  it  is  felt  that  the 
initiation  effort  has  produced  work  that  is  legitimate  and 
valuable  from  a  content  point  of  view. 

The  general  spirit  regarding  the  output  of  the  initiation 
effort  is  that  what  is  good  will  be  retained  for  longer  term  PDES 
work.  All  results  from  the  initiation  effort  are  subject  to 
scrutiny  and  modification  prior  to  possible  acceptance. 

The  initiation  effort  was  administered  by  two  task  groups, 
the  Logical  Layer  Initiation  Task  Group  and  the  Physical  File 
Structure  and  Formal  Language  Committee.  This  report 
concentrates  on  the  activities,  findings,  conclusions,  and 
recommendations  of  the  Logical  Layer  Initiation  Task  Group. 

Beginning  the  overall  PDES  effort  with  a  proof  of  concept 
effort  is  justified.  In  addition  to  major  differences  between 
the  scopes  of  the  IGES  specification  and  the  envisioned  PDES 
specification,  and  in  the  intelligibility  and  sophistication  of 
the  data  to  be  exchanged,  there  are  also  major  changes  in  the 
process  by  which  the  PDES  specification  is  to  be  developed. 
Distinguishing  features  in  this  process  are  given  in  the  next 
subsection.  In  particular,  development  of  the  PDES  specification 
will  recpiire  settling  on  a  methodology  by  which  the  various 
organizational  components  can  work  together.  The  major  emphasis 
of  the  Logical  Layer  Initiation  Task  is  to  gain  experience  and 
make  recommendations  concerning  a  methodology  for  the  development 
process  for  the  PDES  specification. 

1.2  The  Consistency  Between  The  initiation  effort  And  The  Second 

PDES  Report 

The  process  for  the  development  of  the  PDES  specification 
that  was  followed  in  the  initiation  effort  is  consistent  with  the 
requirements  given  in  the  Second  PDES  Report,  a  report 
commissioned  within  the  IGES  Edit  Committee  and  issued  by  the 
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PDES  Chairman  in  late  1984.  This  report  was  presented  to  the 
IGES  Steering  Committee  in  early  1985. 

The  distinguishing  features  of  the  process  according  to  that 
report  are:  use  of  reference  models,  use  of  formal  languages,  a 
minimally  redundant  entity  set,  and  a  three  layer  architecture. 

A  reference  model  is  a  mechanism  for  describing  information. 
The  development  process  outlined  in  the  Second  PDES  Report  placed 
great  emphasis  on  the  use  of  reference  models.  Information  models 
such  as  those  produced  by  the  IDEF-1  amd  the  NIAM  information 
modeling  techniques  are  examples  of  reference  models.  These 
modeling  techniques  are  described  in  primers  in  appendix  D1  and 
D2  respectively. 

The  three  layer  architecture  involves  an  application  layer, 
a  logical  layer,  and  a  physical  layer.  The  following  notions  are 
adequate  for  the  introductory  purpose  here:  The  application 
layer  consists  of  reference  models  constructed  for  various 
application  areas  using  information  modeling  techniques.  These 
models  describe  product  data  for  the  various  areas  from  the 
respective  user  points  of  view.  The  logical  layer  consists  of  a 
reference  model  describing  a  minimally  redundant  set  of  generic 
entities  and  structures  that  play  a  supporting  role  in  describing 
product  data.  This  logical  layer  reference  model  will  be 
referred  to  in  this  report  as  the  "Logical  Layer  Model.”  The 
specific  manner  in  which  these  entities  carry  out  this  role  is 
also  of  importance.  The  physical  layer  consists  of  a  reference 
model  defining  the  actual  physical  format  structure  by  which 
product  data  will  be  exchanged. 

Thus  the  main  pieces,  and  the  flow,  in  the  PDES 
specification  development  process  are: 

(i)  the  user  •  the  process  starts  with  precise,  user 
developed  descriptions  of  the  product  data  to  be  exchanged 

(ii)  the  logical  method  -*  the  process  continues  with  the 
integration  of  the  piecemeal  descriptions  of  product  data  into  a 
logical  whole,  and  with  the  Identification  and  specification  of 
the  manner  in  which  the  information  is  to  be  carried  within  a 
bo\inded  set  of  logical  structures. 

(iii)  the  format  the  process  terminates  with  the  imbedding 
of  the  descriptions  of  the  product  data  into  a  physical  format 
structure . 

The  initiation  effort  has  incorporated  the  distinguishing 
features  of  PDES.  It  has  involved  these  three  pieces,  and  has 
exercised  the  flow  between  them.  Reverse-flow  loops  have  been 
used  for  assuring  quality.  Information  models  have  been  produced 
and  used  in  the  context  of  the  three  layer  architecture.  In 
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particular,  the  activities  of  the  Logical  Layer  Initiation  Task 
Group  have  involved  the  generation  of  application  layer 
information,  and  have  also  involved  specific  deliveradjles  to  the 
Physical  File  Committee. 


1.3  The  Three  Lavers  -  Application  Logical.  And  Physical 

It  is  appropriate  to  summarize  the  descriptions  of  the  three 
layers  as  given  in  the  Second  PDFS  Report.  See  Figure  1-1, 
slightly  modified  from  the  Second  PDFS  Report,  for  a  depiction  of 
the  layers. 

The  top  layer  is  the  user  or  application  layer.  This  is  the 
layer  at  which  the  ultimate  user  lives  and  thinks.  He  formulates 
his  data  requirements  in  his  own  terms  stating  concisely  what  he 
needs.  He  draws  from  his  own  experience  and  from  the  established 
terms,  conventions,  techniques,  and  methodologies  of  his 
discipline.  The  different  application  groups  such  as  Flectrical 
Products  or  Finite  Flement  Modeling  define  the  information 
entities  relevant  to  their  application,  and  construct  reference 
models  for  them.  This  layer  of  the  specification  contains  as 
many  different  applications  and  entities  within  those 
applications  as  there  is  apparent  need  for. 

The  second  layer  is  the  logical  or  conceptual  layer.  This 
is  where  the  data  content  for  the  set  of  generic  entities  and 
structures  is  defined.  This  set  should  be  a  normalized, 
minimumly  redundant  set  that  supports  (is  a  basic  resource  for) 
the  information  defined  by  the  applications.  At  this  layer, 
logical  commonality  will  be  sought  across  all  applications. 
Complex  things,  events,  and  phenomena  in  the  application  layer 
will  be  constructed  from  less  complex  things,  events,  and 
phenomena  in  the  logical  layer  whenever  possible.  Similarities 
in  the  information  requirements  of  different  applications  will  be 
integrated  into  single  conceptual  entities.  The  integration  of 
different  application  requirements  will  control  the  definition  of 
redundant  entities  and  will  help  to  ensure  a  consistent,  coherent 
entity  set.  The  entity  definitions  at  this  layer  will  be  in 
logical  form  in  a  reference  model. 

The  bottom  layer  is  the  physical  or  internal  layer.  This 
layer  contains  one  or  more  actual  file  format  definitions.  It 
consists  of  the  description  of  the  sections,  records,  fields, 
sequencing,  and  associated  formats  for  the  exchange  file.  A 
formal  definition  language  reference  model  will  be  used  to  reduce 
ambiguity. 

1.4  The  Logical  Laver  Initiation  Chapter 

A  mission  for  the  Logical  Layer  Initiation  Task  Group 
consistent  with  the  Second  PDFS  Report  was  developed  in  the  form 
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of  a  charter.  The  charter  was  then  followed  to  the  extent 
possible  for  the  remainder  of  the  effort.  The  charter  is 
included  in  this  report  as  Appendix  F. 


The  two  main  tasks  adopted  by  the  Task  Group  were: 

Task  1:  Develop  a  Logical  Layer  model  that  supports  one 

specific  application  area  model,  and  then  commxinicate 
the  three  part  schema  consisting  of  the  two  models  and 
their  interrelationships  to  the  Physical  File  structure 
and  Formal  Languages  Committee. 

Task  2:  Further  develop  the  Logical  Layer  model  to  support 

additional  application  area  models,  and  ;^ommunicate  the 
three  part  schema  associated  with  each  of  these 
application  area  models  to  the  Physical  File  Structure 
and  Formal  Languages  Committee. 


Thus,  the  Logical  Layer  model  would  serve  as  a  resource  to 
all  the  application  area  models.  Each  three  part  schema  would  be 
expressed  first  as  an  information  model  using  the  Nijssen 
Information  Analysis  Method  (MIAM) ,  and  then  communicated  to  the 
Physical  File  Committee  in  the  form  of  the  Data  Specification 
Language  (DSL).  DSL  is  described  in  a  primer  in  appendix  D3. 

The  intent  of  the  first  task  was  to  cause  to  be  used  all 
layers  of  the  three  layer  architecture.  The  intent  of  the  second 
task  was  to  illustrate  that  the  Logical  Layer  model  could  be 
expanded  as  the  need  arose.  This  was  taken  as  a  characteristic 
of  the  future  PDES  working  environment. 

The  contents  of  the  two  tasks  as  actually  carried  out  are 
presented  in  Figures  1-2  and  1-4.  The  primary  contributors  to 
the  two  tasks  are  presented  in  Figures  1-3  and  1-5. 

For  Task  1,  a  schema  was  developed  supporting  the  mechanical 
products  application  area  of  flat  plates  with  holes.  A  wireframe 
geometry  model  and  a  presentation  (graphics)  model  were  developed 
and  served  as  the  principal  parts  of  the  initial  Logical  Layer 
model.  The  flat  plate  application  area  itself  served  primarily 
as  a  vehicle.  The  primary  intent  was  to  choose  something  simple 
that  would  enable  the  work  to  get  started. 

For  Task  2,  three  additional  application  area  reference 
models  were  developed.  The  three  application  models  were: 

Finite  Element  Modeling,  Electrical  Schematics,  and  Tolerancing. 
To  support  these  additional  application  models,  the  initial 
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Logical  Layer  model  was  further  developed  to  Include  topology  and 
geometry-topology  associativities . 

1.5  Some  Perspectives  On  Data  Exchange  In  The  PDES  Environment 

The  work  within  the  initiation  effort  has  been  directed 
toward  a  methodology  for  the  development  of  the  PDES 
specification  according  to  the  general  guidelines  of  the  Second 
PDES  Report.  That  is,  no  work  has  been  done  that  involves  actual 
data  exchange.  Nonetheless,  since  data  exchange  is  the  ultimate 
task  with  which  the  PDES  effort  must  concern  itself,  we  feel  it 
is  appropriate  to  discuss  this  topic  and  to  pass  along  our 
current  understandings,  caveats,  and  recommendations.  In 
addition,  discussion  of  this  topic  enaibles  us  to  place  o\ir 
initiation  work  in  some  global  perspective.  Unfortvinately,  some 
of  the  material  is  quite  technically  oriented  for  an  introductory 
section.  However,  we  feel  it  is  also  extremely  basic,  and  that 
this  is  the  logical  location  for  it,  and  so  have  resisted  all 
intermittent  urges  to  locate  it  elsewhere. 

1.5.1  Mental  Models.  Discipline-Specific  Entities.  Generic 
Entities.  And  Data  Exchange  Units 

Data  exchange  is  predicated  upon  the  common  awareness 
between  a  sender  and  a  receiver  of  a  "mental  model".  That  is, 
the  sender  originates  his  data  in  terms  of  some  model  which  makes 
the  data  meaningful  to  him.  In  order  to  recover  the  correct 
meaning  of  the  data  in  an  exchange,  the  receiver  must*  share  the 
same  mental  model  as  the  sender. 

For  exzunple,  in  the  use  of  IGES,  drawing  data  could  be  (and 
is)  exchanged  based  on  various  mental  models,  such  as  the  ANSI 
Y14.5  standard  for  dimensioning  and  tolerancing,  MIL-STD  100  for 
drawings,  various  company  standards,  etc.  It  so  happens  that 
each  of  these  mental  models  has  been  developed  externally  to 
IGES. 


With  PDES,  product  data  will  also  be  exchanged  according  to 
mental  models,  but  these  are  more  likely  to  be  developed  as  part 
of  the  PDES  effort  itself.  The  mental  models  will  originate  at 
the  Application  Layer  and  will  be  "standardized".  Exeunples  are  a 
Mechanical  Products  mental  model,  an  Electrical  Products  mental 
model,  an  Architecture,  Engineering  &  Construction  (AEC)  mental 
model,  etc.  Each  mental  model  will  contain  entities  and 
information  specific  to  the  particular  discipline  of  the  mental 
model.  In  fact,  we  will  most  times  use  the  term  "discipline 
model"  instead  of  the  term  mental  model. 

Drawing  again  upon  the  IGES  experience  for  a  moment,  we  see 
that  the  exchange  of  drawings  is  oriented  toward  human 
interpretation  of  the  exchanged  data.  Therefore,  in  the  data 
exchange  process,  it  is  permissable  that  the  exchange  of  the 
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mental  model  be  at  the  human  level.  Reflecting  for  a  moment,  we 
realize  that  the  exchange  of  this  mental  model  actually  takes 
place  when  we  learn  how  to  ''read'*  a  drawing  according  to  a 
certain  set  of  conventions. 

The  situation  with  PDES  is  different.  Product  data 
expressed  with  PDES  is  supposed  to  be  addle  to  be  interpreted  and 
used  by  another  computer.  This  means  that  the  mental  model  must 
be  computer  readable,  must  be  able  to  be  made  explicit  in  the 
data,  and  must  be  eible  to  be  exchanged  with  its  structure  intact. 

Since  PDES  intends  to  address  all  of  product  data,  this 
means  that  the  totality  of  all  discipline-specific  entities  in 
all  discipline  models  is  potentially  unbounded. 

What  are  the  possible  implications  of  this  as  far  as  the 
PDES  specification  itself  is  concerned? 

One  possibility  would  be  to  simply  have  the  set  of  PDES 
entities  be  the  union  of  all  discipline-specific  entities  found 
in  all  discipline  models,  and  to  let  this  be  as  dynzunic  a 
collection  as  required. 

However,  most  CAD/CAM  systems  today,  and  probeOsly  for  some 
time  to  come,  are  predicated  upon  small,  stable  sets  of  "generic" 
context- independent  entities  (eg.,  line,  arc,  string,  group, 
etc.),  rather  than  upon  a  (user-defined)le)  set  of  discipline- 
specific  entities  that  is  open-ended.  This  is  particularly  true 
of  systems  that  strive  to  be  inter-disciplinary. 

Therefore,  these  CAD/ CAM  systems  will  expect  to  interact 
with  PDES  product  data  by  means  of  a  small,  relatively  fixed 
"core"  set  of  generic  entities.  This  is  the  essential  deterrent 
to  simply  having  the  PDES  entity  set  be  a  dyneunic  collection  of 
discipline-specific  entities. 

This  simultaneous  need  to  be  eUsle  to  hemdle  an  open-ended 
n\imber  of  discipline-specific  entities  and  also  to  be  able  to 
communicate  product  data  according  to  the  PDES  specification 
through  a  small,  stable  set  of  generic  entities  is  what  leads  to 
the  notions  of  integration  and  conceptualization.  Integration  is 
the  determination  of  the  rationale  behind  expressing  a  divergent 
set  of  discipline-specific  entities  in  terms  of  one  set  of 
generic  entities.  Conceptualization  is  the  process  of 
abstracting  across  the  different  disciplines  for  the  purpose  of 
arriving  at  a  sufficient,  non-redundant  set  of  generic  entities. 
Conceptualization  also  occurs  within  a  discipline  as  common 
entities  and  structures  are  discovered  that  support  applications 
within  a  discipline.  It  should  be  noted  here  that  the  notion  of 
conceptualization  will  also  be  used  in  a  broader  sense  in  this 
report  to  mean  the  act  of  discovering  and  formalizing  meaning. 
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It  turns  out  that  eibstraction  is  a  major  component  of 
conceptualization. 


Redundancy  in  the  generic  entity  set  is  undesirable  because 
it  opens  the  situation  to  non-viniqueness :  the  discipline- 
specific  entities  could  then  be  expressed  in  terms  of  the  generic 
entities  in  different  ways.  (The  notion  of  espressing  a 
standardized  set  of  discipline-specific  entities  in  terms  of 
generic  entities  is,  historically,  not  an  explicit  part  of  the 
IGES  effort,  although  some  work  toward  making  these  kinds  of 
correspondences  explicit  does  appear  in  IGES  Version  3.0.  There 
is,  however,  redundancy  in  the  IGES  entity  set,  and  this  does 
lead  to  non-uniqueness.  The  lack  of  explicit  correspondences 
further  complicates  matters.  The  term  "flavoring"  has  been 
coined  to  apply  to  this  situation.  We  say  that  IGES  files  are 
"flavored"  according  to  the  user,  the  system,  the  application, 
etc.,  rather  than  expressing  certain  standard  information  in  a 
certain  standard  form. ) 


Suppose  now  that  we  do  relegate  the  development  of  the 
various  discipline  models  to  the  Application  Layer,  and  the 
development  of  the  generic  models  to  the  Logical  Layer.  Analogies 
have  been  given  within  the  PDES  community  to  fvirther  explain  the 
contents  of  the  Logical  Layer,  and  the  relation  between  these  two 
layers : 


The  schema  for  the  generic  entities  (the  Logical  Layer  Model)  is 
akin  to  the  Periodic  Table  of  the  Elements  in  Chemistry.  Just  as 
other  compo\inds ,  are  described  in  terms  of  the  atomic  elements  in 
the  Ted)le,  so  too  are  discipline-specific  entities  described  in 
terms  of  the  generic  data  described  by  the  schema  within  the 
Logical  Layer,  with  respect  to  the  relation  between  the  two 
layers,  we  can  think  for  a  moment  about  cooking.  The  Logical 
Layer  consists  of  data  about  flour,  leavening  agents,  spices, 
etc.  The  application  Layer  contains  receipes  which  combine 
various  subsets  of  the  Logical  Layer  ingredients  to  produce 
cakes,  cookies,  breads,  etc. 

From  the  perspective  of  the  Logical  Layer,  we  believe  then 
that  a  data  exchange  situation  in  the  PDES  context  will  involve 
the  following  three  elements: 

1)  a  discipline  model  that  provides  the  context  for 
interpreting  the  data  for  a  specific  purpose 

2)  the  set  of  generic  entities 


3)  the  set  of  correspondences  from  the  discipline- 
specific  entities  in  the  discipline  model  to  the 
generic  entities 
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For  each  discipline  model,  these  three  elements  form  a  "data 
exchange  unit".  This  unit  must  be  computer  interpretable,  and 
must  be  edsle  to  be  made  explicit  in  the  data  to  be  exchanged. 
Stated  more  precisely,  a  data  exchange  unit  should  be  considered 
as  a  three  part  schema,  and  the  physical  file  data  should  consist 
of  instances  of  this  schema.  (Note  that  items  (1)  and  (3)  are 
missing  in  the  IGES  environment,  as  was  mentioned  above.) 

Clearly,  it  will  happen  that  the  same  generic  entity  will  be 
used  in  different  ways  by  different  entities  within  the 
discipline  models,  possibly  even  within  the  same  data  exchange 
unit. 


Data  exchange  out  of  PDES  then  will  involve  consistent 
actions  applied  to  the  entire  data  exchange  \init.  On  the  basis 
of  the  common  sharing  of  the  discipline  model,  the  receiver  will 
define  his  correspondences  from  the  discipline  model  to  his  own 
generic  entities.  From  this,  the  required  translator  actions 
from  the  PDES  generic  entities  to  the  recipient's  generic 
entities  can  be  determined. 

By  taking  the  correspondence  from  the  PDES  discipline- 
specific  entities  to  the  PDES  generic  entities  into  account,  the 
translator  action  can  be  based  on  information  at  the  Application 
Layer  as  well  as  the  Logical  Layer.  Current  IGES  translators, 
having  no  correspondences  to  draw  upon,  must  determine  their 
actions  based  solely  on  generic  type  information.  These  actions 
are  then  fixed,  either  permanently,  or  at  least  for  an  entire 
exchange  set  of  data. 

We  can  observe  how  this  notion  of  data  exchange  units 
permits  a  clear  separation  of  the  Application  Layer  from  the 
Logical  Layer. 

1.5.2  Requirements  Imposed  On  Users  And  Vendors  Bv  PDES 

Ass\jme  for  the  moment  that  product  data  in  PDES  is  to  be 
expressed  in  terms  of  data  exchange  units  as  described  above. 

What  are  the  requirements  on  users  entering  data  into  their  own 
systems,  and  on  translators,  that  must  be  met  in  order  to  be  able 
to  establish  and  use  the  data  exchange  units  in  PDES? 

We  believe  the  estedslishing  of  data  exchange  \inits  can  be 
done  only  when  a  user's  product  data  is  generated  according  to 
the  seune  units.  For  this,  extensive  analysis  by  users  of  their 
own  application  areas  in  terms  of  the  standard  PDES  discipline 
models  will  be  required,  as  will  strict  adherence  to  standards 
and  conventions  in  entering  the  data  into  the  computer  systems. 
Users  must  set  up  their  own  correspondences  between  the 
discipline  models  and  their  own  set  of  generic  enti'^ies,  and  then 
must  religiously  abide  by  these  correspondences  when  entering 
data  into  their  systems. 
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A  new  generation  of  translators  will  be  required.  Users 
will  have  to  be  edale  to  specify  the  translator  actions  from  the 
generic  entities  of  their  own  system  to  the  generic  entities  of 
PDES  on  basis  of  what  their  own  correspondences  are  between  the 
discipline  model  and  the  generic  entities  of  their  system. 

Similar  requirements  on  translators  for  taking  data  out  of  PDES 
were  given  above. 

1.5.3  The  Data  Exchange  Capability  Represented  Bv  The 
Initiation  Work 

Our  initiation  work  has  not  addressed  the  operational 
aspects  of  data  exchange.  It  has  addressed  only  the  development 
of  the  PDES  specification.  As  a  result,  our  work  has  not 
resulted  in  a  complete  data  exchange  capability.  What  our  work 
has  resulted  in,  however,  is  a  specification  of  PDES  content  and 
a  partial  data  exchange  capability,  "nie  data  exchange  capability 
is  incomplete  because  we  do  not  at  this  time  have  a  formal  and 
computer  readeible  way  of  describing  mappings  between  the 
Discipline  models  and  the  generic  entities  of  the  Logical  Layer 
Model.  This  incomplete  data  exchange  capability  has,  however, 
been  sufficient  to  demonstrate  and  verify  the  capability  of  a 
physical  file  format. 

The  Logical  Layer  initiation  effort  has  basically  addressed 
the  development  of  three  kinds  of  models: 

1.  Discipline  Models 

2.  A  Logical  Layer  Model 

3.  Global  Models 

A  Discipline  Model  represents  an  application  experts  view  of 
a  discipline  area  such  as  flat-plate  design.  All  objects  and 
structures  in  this  model  will  be  created  from  the  view  point  of 
the  application  expert. 

The  Logical  Layer  Model  is  the  summation  of  the  resource 
models:  geometry,  topology,  presentation,  and  geometry-topology 
associativities  and  any  generic  structures  involving 
relationships  across  resource  models.  Resource  models  contain 
only  generic  entities  and  structures  that  are  common  to  many 
application  areas.  The  Logical  Layer  Model  contains  no 
discipline-specific  entities.  The  resource  models  are  described 
in  appendix  Cl,  C2,  C7  and  C8. 

The  Global  Model  is  a  composite  model  that  contains  both 
discipline-specific  and  generic  entities.  The  Global  Model  is  a 
convenient  informal  mechanism  for  expressing  how  objects  in  a 
Discipline  Model  are  replaced  by  generic  objects  from  the  Logical 
Layer  Model.  This  replacement  scheme  is  referred  to  as  a 
"correspondence"  in  this  report.  The  purpose  of  the  Global  Model 
in  the  initiation  effort  is  to  informally  describe  the 
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correspondence  between  each  Discipline  model  and  the  Logical 
Layer  Model.  This  description  is  then  used  to  assist  application 
experts  in  validating  the  correctness  of  the  correspondence.  The 
Global  Model  does  not  represent  an  exchange  unit  as  described  in 
section  1.5.3.  This  model  is  used  in  the  initiation  effort  to 
prototype  an  exchange  content  for  the  purposes  of  validating  the 
physical  file  format. 

We  have  not  completed  the  definition  of  the  data  exchange 
units  as  described  earlier.  Specifically,  we  do  not  at  this  tine 
have  a  formal  technique  for  describing  the  mappings  from  the 
Discipline  Models  to  the  Logical  Layer  Models  or  their  inverses. 
In  lieu  of  this  capability,  the  Global  Model  stands  as  an 
informal  exposition  of  correspondence  between  Discipline  and 
Logical  Layer  models.  We  believe  the  Global  model  has  an 
economy  of  visual  expression  that  makes  it  easy  to  read.  We 
believe  that  this  kind  of  informal  expression  is  a  natural 
precursor  to  more  formal  techniques  of  mapping  and  validating 
and,  in  fact,  we  may  find  it  necessary  to  continue  to  use 
informal  expos it ional  forms  in  conjunction  with  formal  methods  as 
aides  for  hximan  understanding  of  the  specification.  Ideally,  the 
mappings  determined  during  the  development  of  the  specification 
in  follow  on  PDES  efforts  would  be  the  mappings  used  in 
establising  the  data  exchange  tmits  in  an  actual  data  exchange 
situation. 

We  have  provided  a  specific  example  from  the  Electrical 
discipline  to  further  clarify  the  difference  between  the  Data 
Exchange  Unit  and  the  Global  Model.  Figure  1-6  pictures  a  . 
portion  of  a  data  Exchange  Unit  showing  that  a  structure  within 
the  Electrical  Discipline  Model  consisting  of  the  discipline 
objects  "connection  geometry",  "start  place",  "end  place",  and 
"symbol  connection  place"  is  replaced  by  a  generic  structure 
consisting  cf  the  generic  objects  "Composite  segment2",  "Curve 
segment2",  "Place2"  from  the  geometry  resource  model;  "Edge", 
""Vertex"  from  the  topology  resource  model;  and  "Vertex-place", 
"Edge-c\irve"  from  the  geometry-topology  associativity  resource 
model . 

The  Global  Model  described  in  figure  1-7  is  a  "smashed" 
version  of  the  data  exchange  unit  of  figure  1-6.  (This  model  is 
described  in  more  detail  in  figure  4-7.)  The  correspondences 
between  the  Electrical  discipline  model  and  the  Logical  Layer 
Model  are  not  clear  unless  one  exeuaines  the  Discipline  Model  and 
the  Global  Model  together.  Doing  this  one  can  informally  deduce 
the  correspondences  and  can  express  them  in  a  set  of  natural 
language  "replacement"  sentences  as  we  did  in  the  previous 
paragraph.  It  is  conceivable  that  a  Global  Model  could  consist 
entirely  of  Logical  Layer  entities  as  a  result  of  a  complete 
substitution  of  generic  entities  for  discipline  specific 
entities.  As  we  move  closer  to  this  "pure"  Global  Model  with  no 
discipline  flavor,  it  will  become  harder  to  deduce  the 
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correspondences  and  the  need  for  formal  descriptions  of  mappings 
will  become  critical.  We  did  not  reach  this  critical  point  in 
the  initiation  effort. 


If  we  were  to  use  the  Global  Model  in  a  hypothetical  data 
exchange  situation,  the  interpretation  of  the  exchanged  data 
would  then  involve  a  recovery  process  which  would  convert  from 
the  generic  entities  to  the  discipline-specific  information  that 
is  carried  by  the  generic  entities.  Thus,  the  recovery  process 
itself  turns  out  to  be  dependent  upon  a  (mental)  model  that  is 
not  present  in  the  data.  Recall  from  section  1.5.1  that  the 
inclusion  of  the  mental  model  in  the  physical  exhchemge  data 
distinguishes  the  POES  from  IGES;  we  have  fallen  short  of  the 
mark  by  not  having  a  complete  mental  model  in  the  imitation 
effort. 

One  shortcoming  in  this  situation  (of  not  having  implemented 
the  complete  mental  model  that  would  be  mapped  from  the 
discipline  model  to  the  Logical  Layer  explicitly)  is  that  the 
recovery  process  is  stressed  in  terms  of  generic  entities,  and 
must  apply  to  the  entire  set  of  exchange  data.  For  example,  if  a 
certain  type  of  spline  "configuration”  is  to  be  interpreted  as  a 
certain  part  feature,  then  that  configuration  must  have  that 
interpretation  for  the  entire  data  set.  If  splines  are  to  be 
used  also  for  something  else,  and  are  therefore  to  be  interpreted 
differently,  then  something  in  the  spline  "configuration"  must  be 
different.  For  example,  it  coul'd  be  the  case  that-  a  spline  on 
one  level  (i.e.,  one  spline  configuration)  could  be  interpreted 
with  one  meaning,  while  a  spline  on  another  level  (i.e.,  another 
spline  configuration)  could  be  interpreted  with  another  meaning. 

In  the  Electrical  Global  model  (refer  to  figure  4-7)  the 
generic  associativity  "vertex  place"  in  some  instances  plays  the 
discipline  role  of  "Intersection  place"  and  in  other  instances 
the  discipline  role  of  "Symbol  connection  place." 

We  can  observe  how,  with  data  exchange  units,  in  which  the 
mapping  is  in  the  other  direction,  this  situation  is  avoided  as  a 
result  of  the  physical  file  data  containing  instances  of  the  data 
exchange  unit  schema. 

Another  shortcoming  of  the  situation,  that  is,  of  not  having 
implemented  the  mapping  from  the  discipline  model  to  the  Logical 
Layer  Model  explicitly  in  the  data,  is  that  the  clear  separation 
between  the  Application  layer  and  the  Logical  Layer  is  lost.  The 
Global  Model  of  the  Logical  Layer  becomes  a  mixture  of 
application-specific  entities  that  have  not  been  broken  down  into 
generic  entities,  and  generic  entities  that  have  replaced  certain 
application-specific  entities. 


11 


1.5.4  Summary  And  Conclusion 


This  section  has  distinguished  between  writing  a 
specification  for  a  data  exchange  standard/  and  actually  using 
that  standard  to  exchange  data.  The  latter  notion  is  more 
encompassing  in  that  it  also  involves  user  data  bases  and  vendor 
translators.  The  initiation  effort  has  not  involved  actual  data 
exchange . 

This  section  has  also  introduced  the  notion  of  a  data 
exchange  unit  in  the  belief  that  data  exchange  in  the  PDES 
context  must  occur  in  terms  of  these  units. 

Finally,  this  section  has  indicated  what  data  exchange 
capability  our  present  initiation  work  would  afford.  It  is  seen 
that  the  present  capeibility  falls  short  of  the  more  ideal 
situation  in  which  data  exchange  units  are  hemdled. 

It  must  be  pointed  out  that  these  current  thoughts 
concerning  what  data  exchange  in  a  PDES  environment  might 
eventually  involve  are  certainly  not  yet  seasoned  thoughts,  and 
may  very  easily  change  as  we  continue  to  learn  in  connection  with 
the  longer  term  PDES  effort.  We  have  not  yet  had  the  opportunity 
to  thoroughly  discuss  them  with  others  within  the  data  exchange 
community . 

However,  we  can  use  these  thoughts  on  these  topics  to 
illustrate  that  there  exist  many  fundamental  Issues  related  to 
,  the  PDES  effort  that  are  just  now  surfacing.  These  issues  have 
yet  to  be  thoroughly  discusses  or  resolved. 

There  must  be  a  clear  understanding  that,  while  the  PDES 
Project  has  signed  up  for  certain  delivery  dates  for  Version  1.0, 
the  mere  setting  of  these  dates  is  not  to  be  interpreted  as  an 
indication  that  all  work  steps  necessary  for  achieving  them  and 
for  the  successful  use  of  Version  1.0  are  well  understood  in 
terms  of  present  CAD/ CAM  practices,  and  that  all  that  remains  is 
simply  to  routinely  carry  them  out. 

In  fact,  it  is  our  recommendation  that  the  PDES  effort  ought 
not  be  driven  primarily  bv  schedules,  but  rather  bv  an  intention 
to  take  the  time  to  formulate,  analyze,  and  solve  the  substantive 
issues  that  accompany  the  approach  to  developing  the  PDES 
specification  according  to  the  Second  PDES  Report. 


12 


Section  Two 


2.0  The  logical  Laver  Methodology 

The  purpose  of  the  PDES  Initiation  Logical  Layer  Methodology 
is  to  provide  a  framework  in  which  to  guide  the  development  of  a 
single  logical  model  that  will  support  all  applications  within 
PDES.  This  model  will  be  called  the  Logical  Layer  Model. 

The  methodology  described  here  will: 

1.  Maximize  the  usage  of  h\iman  resources  by  defining  and 
establishing  project  roles 

2.  Support  the  development  of  an  informal  correspondence 
(mapping)  between  the  Logical  Layer  Model  and  each 
Discipline  Model 

3 .  Maximize  the  potential  of  the  Logical  Layer  Model 

and  mappings  to  and  from  it  to  serve  as  a  central  resource 
from  which  all  other  PDES  forms  can  be  derived 

2.1  Cognitive  And  Specification  Models 

The  application  and  logical  layer  both  are  responsible  for 
formally  describing  meaning.  The  cpplication  layer  describes 
meaning  within  a  relatively  narrow  subject  area.  The  logical 
layer  describes  meaning  common  to  many  subject  areas. 

♦ 

We  define  conceptualization  as  the  act  of  discovering  and 
formalizing  meaning.  This  definition  holds  regardless  of  the 
size  of  the  s\ibject  area  or  the  nu^er  of  subject  areas.  By  this 
definition,  both  the  application  and  logical  layers  involve 
conceptualization. 

Cognition  is  the  component  of  the  discovery  and  concept 
forming  process  that  emphasizes  human  perception.  Any  modeling 
technique  which  has  as  its  principal  objective  the  promotion  of 
human  perception  of  concepts  (any  concept)  will  be  referred  to  as 
a  cogn3.tive  modeling  technic[ue.  The  result  of  such  a  technique 
will  be  referred  to  as  a  cogntive  model.  In  this  report  we  will 
use  the  terms  "cognitive  model”  and  "conceptual  model" 
interchangeably . 

Abstraction  is  a  major  factor  in  the  concept  forming 
process.  It  is  a  process  whereby  humans  express  qualities  or 
characteristics  of  an  object,  event,  or  phenomenon  apart  from  any 
specific  instance  of  that  object,  event,  or  phenomenon. 

Cognitive  modeling  techniques  promote  the  abstraction  process  by 
providing  simple  means  (usually  graphical)  for  expressing 
objects,  events,  and  phenomena  and  their  interrelationships. 
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Specification  is  the  process  of  packaging  and  reporting  on 
the  results  of  conceptualization.  Any  modeling  technique  which 
has  as  its  principal  objective  the  textual  packaging  of 
conceptual  models  will  be  referred  to  as  a  specification  modeling 
technique.  Specification  is  not  part  of  the  conceptual-model 
building  process.  No  new  concepts  or  relationships  will  be 
discovered  during  specification,  however,  specification  will 
result  in  the  repackaging  of  the  conceptual  model  to  make  it  more 
concise  and  perhaps  more  readable.  Repackaging  involves  grouping, 
concept  typing,  and  naming. 


Cognitive  models  normally  have  a  strong  graphic  component 
and  a  weak  text  component.  Graphics  promotes  human  perception 
through  "picturing”  (picturing  is  not  the  only  means  of  promoting 
human  perception,  however) .  Specification  models  are  purely 
textual  and  structured  into  an  "entity"  form.  The  cognitive 
model  provides  a  clay-like  medium  in  which  the  modeler  can  mold 
concepts.  The  specification  provides  a  casting  medium  to  display 
the  results  of  conceptualization.  In  the  initiation  effort  these 
are  distinct  models. 


These  two  models  must  have  equivalent  descriptive  power  and 
precision  and  they  must  share  a  common  foundation  of  basic 
notions  such  as;  object,  relationship,  proposition,  class,  and 
function  (the  basic  notions  of  first  order  logic) ♦  Both  models 

must  have  a  computer  sensible  representation. _ Each  must  be 

derivable  from  the  other. 


It  is  recommended  for  PDES  follow-on  work  that  concmition 
and  specification  be  recoginized  in  the  Logical  Laver  Methodology 
as  distinct  processes  accomplished  separately  but  in  a 
coordinated  manner.  It  is  our  opinion  that  anv  attempt  to 
combine  these  two  processes  into  a  single  process  will  degrade 
the  quality  of  the  resulting  models.  It  follows  then,  that  the 
use  of  the  Logical  Laver  Methodology  should  result  in  two 
distinct  models;  a  cognitive  model  and  a  specification  model. 


In  the  initiation  effort,  the  NIAM  irreducible  binary  model 
was  selected  as  the  standard  cognitive  model.  More  exactly,  this 
modeling  technicjue  is  referred  to  as  the  MIML  subset  of  the 
Nijssen  Information  Analysis  Method  (NIAM).  (See  Reference  2.) 
This  subset  is  a  semantic-net  language  capabable  of  declaring 
object  types,  object  type  names,  object  roles,  binary 
relationship  types,  object  subtypes,  and  advanced  constraints. 
The  MIML  capability  is  a  subset  of  the  full  NIAM  modeling 
capability.  (The  full  NIAM  constraint  capadsility,  referred  to  as 
Reference  and  Idea  Language  RIDL,  includes  procedural  constraints 
and  advanced  declarative  constraints.)  Hereafter,  in  this 
report,  references  to  NIAM  will  mean  the  MIML  subset  of  NIAM. 

NIAM  is  described  in  a  primer  in  Appendix  D2. 
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Basically,  NIAM  is  a  weakly-typed  semantic-net  language 
which  does  not  force  grouping  of  concepts.  However,  almost  any 
kind  of  grouping  (packaging)  can  be  superimposed  on  models 
developed  with  NIAM. 

DSL  was  selected  for  the  initiation  effort  as  the  standard 
specification  model.  DSL  is  a  variant  of  the  language  used  to 
specify  the  PDDI  conceptual  schema.  This  language  is  described 
in  a  primer  in  Appendix  D3. 

Basically  DSL  is  a  strongly-typed  linear  language  for 
packaging  the  objects  in  conceptual  models  into  groups  called 
"entities”.  DSL  has  the  advantage  that  it  does  not  force  any 
particular  grouping  style  on  the  NIAM  models  (such  as  the  popular 
data  base  normal  forms) .  Grouping  is  the  critical  link  between 
the  cognitive  model  and  the  specification  model.  The  basic 
organizational  mode  of  DSL  is  the  nested  array.  Nesting  allows 
more  concise  and  natural  descriptions  of  PDES  artifacts.  DSL  does 
not  demand  that  the  cognitive  model  be  nested,  however. 

No  single  modeling  technique  was  stipulated  for  the 
application  layer.  IDEF-1  was  the  technique  of  choice  in  several 
areas.  (See  the  primer  in  Appendix  Dl.)  Some  preferred  to  model 
directly  using  specification-like  text  models  similar  to  DSL. 


2.2  Overview  Of  The  Methodology 

The  methodology  is  illustrated  in  Figure  2-1.  It  breaks  the 
development  of  models  into  phases,  defines  interfaces  between 
phases,  and  assigns  project  roles.  These  are  the  phases: 

Phase  1:  Qualification 

Phase  2:  Global  Conceptualization  and  Integration 

Phase  3 :  Specification 

The  input  to  the  methodology  is  a  set  of  discipline  models. 
In  the  initiation  effort  these  models  include  the  Flat  Plate 
Mechanical  Part,  Finite  Element  Modeling,  Electrical  Schematic, 
and  Tolerancing  application  area  models. 
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METHODOLOGY  ARCHITECTURE 


Exchange  Format 


The  ultimate  dellvera^dles  of  the  methodology  are  as  follows: 

1.  All  of  the  Discipline  models  in  a  standard 
cognitive  model  form 

2.  A  Global  Model  for  each  Discipline  Model  in  a 
standard  cognitive  model  form 

3.  A  map  between  each  Discipline  Model  and  its  Global 
Model  (this  was  not  formally  accomplished  in  the 
initiation  effort) 

4.  A  Specification  Model  of  each  Global  Model  in  a 
standard  specification  form 

It  should  be  emphasized  that  the  methodology  is  independent 
of  any  particular  modeling  technique  (with  the  exception  of  its 
cognition,  specification  cateogry) .  The  methodology  should  be 
viewed  as  a  broad  framework  stipulating  two  modeling  forms,  the 
cognitive  form  and  the  specification  form. 

2.3  De_scription  Of  The  Methodology 

Phase  li  Qualification 

Goal:  To  maximize  the  global  conceptualization  and 

integration  potential  of  the  discipline  models 

Input:  Discipline  models  (in  any  modeling  language) 

Deliverable:  Discipline  models  (in  a  standard  cognitive  form) 

This  phase  actually  represents  an  interface  to  the 
Application  Layer  and  insures  that  all  discipline  models  appear 
in  a  \iniform  language  that  maximizes  the  chances  for  successful 
global  conceptualization  and  integration.  The  assximption  we  are 
madcing  at  this  time  is  that  no  stemdard  Application  Layer 
modeling  language  will  be  stipulated.  This  does  not  prevent  the 
application  layer  from  selecting  the  standard  cognitive  model  as 
its  modeling  choice.  If  the  cognitive  language  is  powerful 
enough  to  express  the  global  abstractions  (concepts)  of  the 
logical  layer  it  is  powerful  enough  to  express  the  discipline 
abstractions  (concepts)  at  the  application  layer.  This  phase 
thus  allows  for  the  fact  that  modeling  languages  used  at  the 
Application  Layer  may  not  be  the  best  languages  for  the  extensive 
conceptualization  that  must  be  done  at  the  Logical  Layer. 

In  summary,  this  phase  buffers  the  Logical  Layer  from  the 
variety  of  languages  at  the  Application  Layer,  and  also  paves 
the  way  for  the  extended  conceptualization  that  must  occur  in  the 
Logical  Layer. 
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A  discipline  model  is  said  to  be  ■’qualified"  when  it  is 
determined  that  the  discipline  model  in  standard  form  is 
equivalent  to  the  discipline  model  in  native  form.  Ideally  this 
phase  of  the  methodology  should  be  concerned  with  translating  the 
Discipline  model  to  a  standard  cognitive  form.  Any  validation 
done  in  this  phase  should  be  for  the  purposes  of  insuring  that 
the  meaning  of  the  Discipline  model  has  been  preserved  in 
translation  to  the  cognitive  form. 

It  is  not  the  responsibility  of  the  Logical  Laver  to  perform 
discipline  modeling,  however,  they  do  have  the  responsibility  to 
read  and  understand  the  discipline  models  and  request 
clarification  or  correction  to  the  models  if  needed. 


Phase  1  roles  identified: 

1.  Model  Translator  -  This  person  must  be  familiar  with  the 
particular  discipline  modeling  language  and  the  standard 
conceptual  modeling  language  of  the  Logical  Layer. 

2.  Discipline  Liaison  >  This  role  requires  that  the 
participant  be  familiar  with  the  discipline  and  the 
particular  modeling  language  of  the  discipline.  It  would 
be  ideal  if  the  participant  were  also  familiar  with  the 
Logical  Layer  standard  modeling  language.  This  is  an 
extremely  demanding  role. 


Phase  2:  Global  Conceptualization  and  Integration 

Goal:  To  discover  and  formally  model  generic  objects,  events, 

and  phenomena  (referred  to  as  resources)  that  are 
common  to  all  disciplines  and  determine  how  they  can 
be  used  to  replace  discipline  specific  objects,  events, 
and  phenoema. 


Input:  A  Qualified  model  of  each  discipline 


Deliverable:  1.  A  set  of  resource  models  containing  only 

generic  objects,  events,  and  phenomena 
(the  set  of  all  resource  models  is  referred 
to  as  the  Logical  Layer  Model) 

2.  A  Global  model  that  formally  describes  how  each 
Discipline  model  is  represented  in  terms 
of  the  generic  objects,  events,  and  phenomena 
of  the  resource  models.  The  union  of  these 
Global  models  represents  the  model  universe 
of  PDES. 
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This  phase  is  the  most  challenging  of  the  three  phases  and 
is  the  heart  of  the  methodology.  The  Logical  Layer  tezun  believes 
that  the  discovery  and  formalization  of  generic  objects,  events, 
and  phenomena  across  the  diverse  disciplines  within  PDES  is  a 
task  that  has  never  been  accomplished  before.  Admittedly,  this 
phase  of  the  methodology  will  evolve  over  time  as  we  become  more 
mature  in  conceptualizing  over  diverse  application  areas.  This 
kind  of  conceptualization  will  require  broad  knowledge  of  many 
application  areas  on  the  paart  of  logical  layer  workers  in 
addition  to  mature  modeling  skills.  The  ability  to  adsstract  very 
general  structures  and  semantic  classes  will  be  critical.  It  is 
felt  that  this  extreme  form  of  abstraction  goes  beyond  the  usual 
notion  of  abstraction  that  is  attached  to  the  process  of 
conceptualization  of  more  restricted  domains  of  discourse. 

A  set  of  baseline  tasks  are  suggested  for  beginning  the 
Phase  2  global  conceptualization  effort.  Evolution  to  more 
mature  techniques  of  global  conceputalization  would  be  expected 
to  occur  from  this  baseline. 


Baseline  tasks: 

1.  Develop  a  set  of  concept  categories.  To  the  greatest 
extent  possible,  these  categories  will  be  generic  in  that 
they  may  be  used  across  a  broad  set  of  disciplines.  Ideally 
these  categories  can  be  discovered  as  the  discipline  models  are 
being  qualified  in  Phase  1- (bottom  up),  or  they  may  need  to  be 
adopted  provisionally  on  the  basis  of  general  Jcnowledge 
derived  from  other  sources  such  as  I6ES,  PDDI,  PHI6S,  etc. 

(The  latter  was  the  case  in  the  initiation  work  with  the 
resource  models  of  wireframe  geometry,  topology,  and 
presentation. } 

2.  Develop  a  set  of  structural  categories.  A  structure  in 
this  case  is  a  recognizable  pattern  of  interrelated  concepts  that 
appear  in  multiple  discipline  models.  (We  assume  when  referring 
to  a  discipline  model  that  it  is  qualified. ) 

3.  Examine  each  discipline  model  and  attempt  to  factor  it 
completely  into  generic  concepts  and  structures  and 
discipline-specific  concepts  and  structures.  Denote  generic 
concepts  and  structures  so  they  can  be  clearly  identified.  The 
resulting  model  will  be  referred  to  as  the  Global  model  in  this 
methodology.  Generic  concepts  in  the  Global  model  are  denoted  by 
containing  them  within  a  closed  dotted  line. 

4.  Once  the  discipline  model  has  been  converted  to  Global-model 
form,  logical  layer  workers  in  cooperation  with  the  application 
liaison  person  verify  that  the  qualified  discipline  model  can  be 
recovered  from  the  Global  model.  They  should  record  this 
recovery  process  in  a  formal  language.  If  no  formal  mapping 
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language  is  availeUsle,  the  recovery  process  should  be  recorded  in 
sentence  form.  It  should  be  emphasized  here  that  ^e  main 
purpose  of  the  Global  model  is  to  prbvide  a  convenient  exposition 
for  showing  the  correspondence  (mapping)  between  a  discipline 
model  and  its  corresponding  Global  model.  It  is  not  to  be 
considered  an  exchemge  model  per  se.  Please  relate  this  section 
with  the  discussions  in  section  1.5.3.  In  the  initiation  effort, 
the  Global  model  is  the  only  mechanism  for  showing  the 
correspondence  between  a  discipline  model  and  its  corresponding 
Global  model.  We  did  not  develop  a  formal  mapping  language  in  the 
initiation  effort.  Some  mappings,  however,  are  expressed  in 
natural  language  in  this  report. 

5.  Any  new  generic  concepts  or  structures  that  may  have  been 
discovered  during  the  conversion  of  discipline  models  to  Global 
models  should  be  formally  noted.  Previous  discipline  models 
should  be  reviewr^d  again  to  see  if  any  of  the  new  generic 
concepts  or  structures  can  replace  discipline  specific  concepts 
or  structures  in  those  models. 


In  siommary,  the  process  is  heuristic.  In  the  initiation 
effort  a  baseline  of  entities  known  to  be  generic  (geometry  and 
presentation)  was  first  modeled  into  a  Task  1  Logical  Layer  Model 
in  order  to  get  the  project  off  the  ground.  Ideally  all  generic 
entities  would  be  discovered  in  the  process  of  discipline 
modeling.  It  is  difficult  to  estziblish  a  recipe  for  global  model 
building.  Basically,  this  phase  keeps  substituting  and/or 
expanding  concepts  and  structures  in  the  discipline  models  in 
terms  of  generic  concepts  and  structures  to  the  maximtxm  extent. 

The  summation  of  all  the .Global  models  constitutes_the 
conceptual-model  universe  for_PDES.  The  collection  of_all 
qualified  discipline  models,  the  correspondences  froappinos). 
between  the  Global  model  and  the  qualified  discipline  models,  and 
the  summation  of  all  the  Global  models  will  be  referred  to  as  the 
I.nteqrate,d  mode;. 

Inteqration  is  defined  in  this  methodology  as  the  a.ct_of 
creating  the  Integrated  model. 

Phase  2  roles  identified: 


1. 


2. 


Conceptual  modeler  with  broad  discipline  knowledge 
Discipline  liaison 


Phase  3;  Specification 

Goal:  To  package  each  Global  model  into  a  concise,  aggregated 

(entity-based)  form. 

Input:  Global  models 

DelivereUsle:  A  specification  model  for  each  Global  model 

This  phase  involves  the  translation  of  each  Global  model  to 
some  standard  text  form  called  "the  specification”.  Ideally, 
this  phase  would  not  involve  additional  conceptualization.  The 
translation  to  the  specification  should  not  delete  detail 
(although  it  may  abstract  out  detail  through  the  strong  typing 
capedsility  of  the  specification  language)  or  add  new  meaning 
(except  that  which  may  be  assigned  to  groups  and  types) .  The 
principle  difference  between  the  specification  and  the  Global 
model  is  that  some  form  of  grouping  has  been  applied  in  order  to 
make  the  Global  model  more  compact.  Grouping  is  done  based  on 
the  concepts  and  relationships  present  in  the  global  cognitive 
model  and  is  the  critical  link  between  the  Global  model  and  the 
specification  model.  Grouping  is  done  for  the  purposes  of 
achieving  compactness  and  read2d3ility  not  for  the  purposes  of 
achieving  further  conceptualization.  Grouping  is  not  done  for 
the  purposes  of  achieving  a  logical  record  design  in  preparation 
for  implementation  design.  The  specification  is  text  only, 
whereas  the  global  model  can  be  expected  to  be  a  mixture  of 
graphics  and  text. 

Ideally,  the  translation  from  the  global  model  to  the 
specification  model  would  be  automated.  It  was  a  manual  process 
in  the  initiation  effort.  Since  the  methodology  just  described 
does  not  force  any  particular  model  or  specification  language,  it 
cannot  provide  the  details  of  translation.  However .  our 
ejcperience  in  the  Initiation  Effort  indicates  that  the 
development  of  the  global  modeling  language  and  the  specification 
modeling  language  should  be  a  coordinated  effort  to  insure  that 
syntactical  constructs  in  one  have  eouivalent  constructs  in  the 
other. 

Likewise,  the  methodology  does  not  provide  a  technique  for 
grouping  of  global  models.  In  the  initiation  effort  grouping  was 
a  joint  effort  between  conceptual  modelers  and  specifiers. 

It  should  be  emphasized  that  the  resulting  specification 
models  represent,  in  a  concise,  textual  form,  the  correspondences 
between  discipline  models  and  their  Global  model  counterparts. 

The  specification  does  not  represent  an  exchange  mechanism  per 
se.  However,  in  the  initiation  effort,  since  this  is  the 
mechanism  for  transmitting  PDES  information  content  to  the 
physclal  layer;  the  specification  serves  the  role  of  being  an 
exemplary  exchange  for  the  purposes  of  testing  the  physical  file 
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format.  It  is  recognized  that  the  exchange  unit  as  described  in 
section  1.5.1  will  ultimately  replace  the  Global  model  as  the 
principal  mechanism  for  representing  the  correspondence  between 
discipline  models  and  the  generic  objects  in  the  Logical  Layer 
Model.  The  input  to  this  phase  would  then  be  logical  exchange 
units  instead  of  Global  models. 

Phase  3  roles  identified: 

1.  Specifier  -  This  person  is  responsible  for  creating  the 
specification.  This  person  coordinates  with  a  Logical 
Layer  person  to  perform  grouping  emd  translation. 

2.  Logical  Layer  Liaison  -  This  person  works  with  the 
specifier  to  coordinate  the  grouping  of  the  global 
model.  This  grouping  should  be  a  coordinated 
effort  as  the  groupings  are  the  main  link  between  the 
Global  model  and  the  specification. 

2.4  Choice  Of  Modeling  Techniques 

This  section  discusses  the  selection  of  modeling  technic[ues 
for  the  three  phases  of  the  methodology. 

For  Phase  1  (Qualification)  and  Phase  2  (Global 
Conceptualization  and  Integration) ,  a  cognitive  language  was 
chosen  because  human  perception  and  abstraction  are  the  principal 
activities  involved  in  these  two  phases.  For  Phase  3 
(Specification) ,  a  specification  language  was  chosen. 

The  logical  layer  had  no  jurisdiction  over  selection  of 
languages  to  be  used  at  the  application  layer.  For  the  most 
part,  discipline  models  were  modeled  in  IDEF-1. 

Cognitive  Language  Choice 

For  Phase  1  and  2,  the  Nijssen  Information  Analysis  Method 
(NIAM)  was  chosen  as  the  standard  modeling  technique.  NIAM  is  a 
semantic  modeling  technique.  It  emphasizes  elementary  concepts 
and  binaxry  relationships.  The  following  is  a  summary  of  NIAM 
strengths : 

1.  It  has  international  recognition. 

2.  The  method  is  the  piiblic  domain  (MIML  subset). 

3.  There  is  a  body  of  people  with  experience  in  the  methodology 
on  several  continents. 

4.  It  is  oriented  towards  a  s;ib  set  of  natural  language. 
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5.  It  has  a  rigorous  formal  basis  in  classical  and  linguistics 
and  logic. 

6.  It  has  a  formal  grammar  (BNF) . 

7.  It  is  a  purely  semantic  technique  and  involves  no  grouping. 

8.  It  is  detail  exposing. 

9.  It  is  a  bridge  to  advanced  knowledge  representation 
techniques . 

10.  It  has  strong  constraint  representation  capability. 

11.  Computerized  tools  are  commercially  availaLble  to  support 
model  creation  and  access,  dictionary  management,  and 
graphical  output. 

We  emphasize  again  that  Phase  1  and  2  are  cognitive 
activities.  In  these  phases,  nothing  should  interfere  with  the 
processes  of  perception,  concept  discovery,  or  the  exposition  of 
detail.  We  specifically  against  modeling  techniques  which 

attempt  to  combine  conceptualization  and  grouping  or 
conceptualization  and  sr -cification.  We  believe  these  techniques 
will  not  yield  the  h-’gh  quality  models  needed  for  integration. 

We  have  specifically  not  chosen  the  entity-attribute- 
relationship  type  of  model  because  it  mixes  the  conceptualization 
and  grouping  processes,  it  forces  the  modeler  to  artificially 
separate  concepts  into  entities  and  attributes,  it  does  not 
sufficiently  expose  detail,  and  it  does  not  graphically 
represent  advanced  constraints. 

IDEF-1  is  a  hybrid  modeling  technique  that  combines  aspects 
of  entity-attribute-relationship  modeling  and  relational 
modeling. 

For  a  formal  comparison  of  the  binary  approach  and  the 
entity-attribute-relationship  approach,  the  reader  is  referred  to 
Reference  3,  IS0/TC97/SC21/WG5-3  report  SC21-N197,  Appendix  D  and 
E. 


specification  Language  Choice 

The  Data  Specification  Language  pSL)  was  chosen  as  the 
standard  specification  modeling  technique  for  the  initiation 
effort.  It  has  the  following  strengths: 

1.  It  is  compact  and  purely  text. 

2.  It  has  a  text  structure  that  is  easy  to  read. 
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3.  It  is  strongly  typed  to  support  abstraction. 

4.  It  has  a  formal  grammar  (BNF) . 

5 .  It  has  a  close  relationship  to  the  binary  model . 

6.  It  has  potential  for  addition  of  advanced  constraints. 

7.  It  has  a  basic  organizational  foundation  (nested  array) 
that  promotes  representation  of  complexity  in  a  natural  way 

DSL  is  a  derivative  of  the  language  used  to  specify  the  PDDI 
conceptual  schema.  A  primer  on  DSL  contained  in  Appendix  D3. 
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Section  Three 


3 . 0  Application  And  Resource  Areas 

This  section  consists  of  a  brief  overview  of  the  major 
application  and  resource  areas  used  in  the  initiation  effort. 

On  the  one  hand,  given  that  the  main  emphasis  in  the 
initiation  effort  is  on  methodology,  the  use  of  these  content 
areas  and  their  corresponding  models  is  strictly  as  a  means  to  an 
end.  On  the  other  hand,  the  content  itself  does  deserve 
exposition.  It  was  developed  using  the  modeling  approach,  and 
the  people  involved  represent  a  fairly  broad  cross-section  of 
standing  IGES  technical  subcommittees;  specifically,  the  Curves 
and  Surfaces  subcommittee,  the  Finite  Element  Modeling 
subcommittee,  the  Electrical  Applications  svibcommittee ,  and,  in 
the  case  of  the  Tolerancing  application  model,  the  Chairpersons 
of  the  Manufacturing  Technology  subcommittee,  the  Drafting 
subcommittee,  and  the  Mechanical  Products  subcommittee. 

Recall  that  resource  models  describe  the  entities  used  as 
generic  entities.  Global  models  then  describe  discipline 
specific  entities  in  terms  of  these  resource  entities. 

Each  overview  statement  below  was  written  either  by  the  task 
leader  of  the  area  being  described  or  by  a  person  intimately 
involved  with  the  development  of  the  model  for  that  area. 


3 . 1  wireframe  Geometry  Resource  Area  -  Edward  Clapp.  IBM  - 
Chairman.  IGES  Curves  And  Surfaces  Subcommittee 

The  Wireframe  Geometry  Proposal  is  intended  to  meet  the  PDES 
geometric  needs  for  points  amd  curves.  Among  its  design  criteria 
were: 

-  ability  to  meet  the  geometric  needs  of  CAD  systems; 

-  ability  to  meet  the  geometric  needs  of  Numerical  Control ; 

-  ability  to  be  extended  in  a  uniform  manner  to  surfaces; 

-  high  priority  to  meet  the  needs  of  Boundary 
Representation  Solid  Modeling; 

-  ability  to  symbolically  represent  much  of  the 
information ; 

-  minimal  entity  set  with  simple  and  uniform  definitions; 

-  stable  representations  for  the  geometry. 
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The  primitive  data  types  are 

-  reals; 

-  integers; 

-  booleans; 

■*  character  strings  (so  as  to  be  able  to  refer  to 

significant  information  by  name  rather  than  by  value) . 

The  basic  building  blocks  are  arrays.  2  dimensional  and  3 
dimensional  geometry  have  been  separated.  Consequently  the  most 
commonly  used  arrays  are  ordered  pairs  and  ordered  triples.  These 
are  used  for  position  and  direction.  Ordered  lists  are  also  used 
for  the  composite  curve. 

The  geometry  itself  consists  of  points  and  curve  segments.  A 
point  is  defined  in  terms  of  its  position  in  space,  either  by 
name  or  by  value.  A  curve  segment  is  defined  in  terms  of  its 
underlying  curves,  endpoints,  and  its  direction.  The  curve  and 
end  points  may  be  defined  either  explicitly  or  referred  to  by 
name.  This  reference  by  name  allows  for  symbolic  statements 
about  intended  continuity  conditions. 

The  curves  (both  2D  and  3D)  are 

-  line; 

-  circle; 

-  ellipse; 

-  hyperbola; 

-  parzdsola; 

-  nonuniform  rational  B-spline; 

-  composite  curve. 

Deficiencies: 

-  offset  curves  were  omitted; 

-  geometric  tolerancing,  while  present,  is  inadequate; 

-  no  means  to  allow  for  user  defined  parametrization; 

-  pareunetric  evaluation  capedsilities  need  to  be  fit  into 
this  schema; 

-  a  certain  amount  of  apparent  complexity  has  been 
introduced,  which  perhaps  can  be  resolved  at  the  DSL 
and/or  file  structure  level. 

It  must  be  noted  that  this  approach  has  generated  some 
controversy.  There  are  a  nuxober  of  entries  in  the  Curve  and 
Surface  document  list  dealing  with  this,  including  two  alternate 
proposals. 

3.2  Presentation  Resource  Area  -  Richard  C.  Winfrey,  Digital 

Equipment  Corporation  -  Member.  IGES  General  Assembly 

PDES  is  intended  to  allow  the  exchange  of  all  data  necessary 
for  the  manufacture  of  a  product.  Here,  manufacturing  is  taken 
in  its  broadest  sense.  Strictly  speaking,  the  specification  of 
product  data  could  conceivably  be  done  without  making  allowances 
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for  displaying  that  data.  In  this  sense,  presentation  data  is 
not  a  PDES  requirement.  However,  it  was  felt  that  information 
required  to  reconstruct  the  saune  presentation  (eg.,  graphics 
display  for  now,  possibly  engineering  drawing  for  later)  of 
product  data  on  both  a  sending  and  a  receiving  system  was  an 
important  capadaility  and  should  be  included  as  part  of  the  PDES 
specification.  In  addition,  it  was  realized  that  in  the  existing 
IGES  specification,  the  data  defining  certain  entities  was 
intertwined  with  display  attribute  data  for  those  entities.  The 
approach  to  avoiding  a  repetition  of  this  undesirable  situation 
was  to  include  presentation  as  a  work  item  in  the  PDES  start-up 
activity,  i.e.,  the  PDES  initiation  effort,  2md  in  that  work  item 
insure  that  the  two  kinds  of  data  did  not  get  intertwined. 

In  defining  the  Presentation  functionality,  it  was  important 
to  decide  whether  just  a  picture,  or  the  information  necessary  to 
CREATE  the  picture,  should  be  included.  The  exchange  of  just  the 
picture  would  be  relatively  simple,  and  could  be  done  by 
specifying  an  existing  standard  for  a  meta-file  such  as  found  in 
GKS(2D).  However,  it  was  recognized  that  the  need  is  to  exchange 
information  to  create  the  display.  The  display  of  a  part  could 
thus  be  created  from  the  actual  geometry  exchanged  rather  than 
from  an  independent  and  separate  list.  In  addition,  the 
receiving  system  would  sxibsequently  be  able  to  manipulate  the 
view  of  the  displayed  part,  and  to  perform  editing  functions  on 
it. 


Having  made  the  above  decision,  and  after  evaluating  the 
functionality  found  in  IGES,  it  was  obvious  that  what  was  needed 
was  a  subset  of  a  graphics  standard.  This  subset  would  provide 
for  view  operations  (i.e.,  a  3D  viewing  pipeline)  and  a  display 
capability  for  geometry  and  text.  Because  of  these  rather 
limited  needs,  any  one  of  CORE,  GKS-3D,  or  PHIGS  would  suffice 
for  defining  the  viewing  pipeline.  However,  it  was  felt  that 
PHIGS  had  a  clear  advantage  over  the  others  because  of  its  use 
of  a  hierarchically  structured  display  list. 

A  PDES  Presentation  draft  specification  was  prepared  in 
mid-1985  based  primarily  on  the  then-current  PHIGS  specification. 
The  one  deviation  from  PHIGS  was  in  the  area  of  text,  where  the 
CG-VDI  specification  was  followed. 

The  current  status  of  the  PDES  Presentation  effort  is  as 
follows: 

1.  The  Presentation  draft  proposal  is  currently  the 
subject  of  a  mail  ballot  of  the  IGES  community. 

Results  will  presxomably  be  made  known  at  the  Raleigh 
IGES  meeting  beginning  April  28,  1986. 
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2.  The  Presentation  draft  proposal  has  been  formally 
submitted  to  the  ANSI  X3H3  committee  (PKIGS)  along 
with  a  list  of  requested  modifications  to  the  PHIGS 
specification.  It  has  received  a  preliminary  review 
by  that  group,  and  while  some  differences  were 
expressed,  they  were  very  willing  to  work  with  us  to 
better  understand  our  needs  and  to  resolve  those 
differences. 

3.  The  ISO  TC184/SC4/WG1  group  has  recently  rejected  the 
Presentation  draft  proposal  in  favor  of  GKS*‘20.  As 
discussed  above,  this  would  limit  the  PDES 
Presentation  functionality  to  that  of  exchanging 
pictures  only,  since  it  would  then  be  impossible  to 

recover  3D  information  at  the  receiving  sytem. 

« 

3.3  Topology  Resource  Area  -  IGES  ESP  Committee 

A  provisional  topology  model  was  added  approximately  midway 
through  the  initiation  effort.  It  was  added  because  no 
siginificant  amount  of  global  conceptualization  could  be 
accomplished  without  it.  The  model  developed  is  a  pure  topology 
model  in  that  it  does  not  refer  to  geometry.  The  model  is 
basically  derived  from  the  IGES  ESP  work.  The  model  was  developed 
directly  in  NIAM  by  the  logical  layer  and  contains  the 
topological  notions  vertex,  edge,  loop,  face,  and  shell.  There 
is  no  claim  for  this  to  be  the  "real"  PDES  offering  for  topology. 
The  need  for  the  model  surfaced  while  performing  global 
conceptualization  of  the  tolerance  model.  The  tolerance 
application  group  actually  supplied  their  own  topology  model  (in 
PASCAL-like  syntax) . 

Some  may  consider  that  the  use  of  a  full-blown  topology  model  to 
overkill  for  modeling  simple  connectivity.  The  problem  was  that 
simple  connectivity  appeared  in  application  models  several  times, 
each  time  modeled  in  a  different  way.  We  had  a  desire  to 
establish  a  uniform  way  of  representing  simple  connectivity 
across  all  applications. 

The  development  of  the  topology  model  also  motivated  another 
resource  model  that  we  have  called  GTA  (geometry-topology 
associativity) .  Over  several  months  of  modeling  we  have  found  a 
class  of  relationships  between  geometry  and  topology  that  have 
potential  for  general  application.  We  foiuid  numerous  occassions 
where  it  did  not  seem  to  make  sense  to  associate  a  particular 
fact  to  geometry  by  itself  or  topology  by  itself.  It  does  not 
make  sense  to  paint  a  topological  face  nor  to  paint  an  unbounded 
surface.  We  have  heard  such  expressions  as  "topology  sits  on  tcp 
of  geometry."  We  choose  to  avoid  subordinating  one  to  the  other 
by  bringing  them  together  as  peers  through  the  GTA 
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associativities.  We  also  had  a  strong  desire  to  be  jdale  to  refer 
to  pure  topology  without  any  other  baggage  (such  as  geometry) 
being  attached. 

We  realize  that  we  stand  in  err  if  "face"  and  "shell"  are  not  to 
be  interpreted  as  purely  topological  objects  but,  more 
specifically,  as  objects  of  the  boundary  representation  scheme. 
Our  topology  model  states  that  a  face  is  a  connected  region  with 
a  boundary  defined  by  a  loop.  The  question  is:  does  it  make 
sense  to  talk  about  a  connected  region  without  referring  to 
geometry? 

In  sinnmary  we  expect  topology  to  be  one  of  the  most  valuable 
resources  in  global  conceptualization  in  future  PDES  efforts. 

The  initiation  effort  learning  experience  more  than  justified  the 
"stubbing  in"  of  a  temporary  topology  model. 

3.4  Electrical  Schematic  Application  Area  -  Curt  Parks. 

General  Dynamics.  Pomona  Division  -  Member.  Electrical 

Applications  Subcommittee 

The  electrical  schematic  is  a  subset  of  the  information 
needed  to  define  an  electrical  product.  It  was  selected  for  the 
initiation  task  because  of  the  number  of  model  entities  involved 
(about  30) .  These  could  be  worked  into  a  normalized  model  and  a 
consensus  achieved  by  the  Electrical  Applications  Committee  (EAC) 
within  the  allocated  time  period. 

The  basis  of  the  model  was  a  Printed  Wiring  Assembly  (PWA) 
model  which  had  been  constructed  the  year  prior.  The  PWA  model 
purpose  was  to  identify  the  logical  information  and  relationships 
needed  in  IGES  for  Version  3.0  to  support  the  transfer  of  all  PWA 
CAD  data.  The  schematic  entities  constituted  about  half  of  the 
PWA  model.  In  turn,  the  schematic  is  applicedsle  to  all 
electrical  packaging  technologies  and  could  form  the  basis  of  a 
broad-scope  PDES  information  set.  The  schematic  is  also  an  early 
element  in  an  electrical  product  life-cycle.  As  such  it  is  used 
to  define  the  functionality  for  the  product  design  and  for  design 
analysis.  Later  in  the  life-cycle,  a  packaging  technology  is 
selected  (e.g.,  a  PWA  or  a  Hybrid  Microelectronic  Assembly).  The 
schematic  then  becomes  a  reference  information  document  used  when 
defining  product  test  requirements  and  logistical  support. 

In  addition  to  the  information  entities  from  the  PWA  model, 
the  logical  development  methodology  also  required  a  user  view  and 
some  entity  refinement.  Both  were  used  to  remove  implementation- 
specific  data  from  the  model.  The  resultant  model  was  also 
converted  from  IDEF-1  to  the  IDEF-1  Extended  format.  Then  the 
model  was  successively  reviewed  and  refined  by  the  EAC  members. 
When  the  model  was  felt  to  fully  support  the  user  view  (i.e., 
could  be  searched  to  derive  a  net  list  and  a  part  list 
information  set) ,  the  relationships  and  attributes  were 
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normalized  by  entering  the  model  into  a  "Metamodeler"  database  at 
General  Dynaunics  Pomona  Division.  The  database  was  passed  into 
the  JAKUS  modeler  (JANUS  is  a  product  owned  by  D.  Appleton  Co.). 
The  JANUS  diagrauns  and  the  Metamodeler  listings  were  used  to 
normalize  the  model  which  was  drawn  on  three  A-size  diagrams  on  a 
general  purpose  graphics  design  system. 

The  model  was  then  submitted  for  integration  with  the 
remaining  PDES  Initiation  task  application  models.  During 
integration  reviews,  several  entities  were  re-defined.  The  new 
entitles  allowed  integration  with  the  geometry  entities  of  the 
other  applications.  The  resultant  model  (now  on  4  sheets)  was 
reviewed  by  SAC  members.  The  Metamodeler  datedsase  was  updated 
and  the  attributes  migrated  as  required  for  the  final  model 
normalization . 

The  key  conceptual  element  present  in  this  model  has  been 
termed  "connectivity”.  The  concept  is  not  limited  to  electrical; 
it  also  defines  how  a  road  becomes  part  of  a  highway  network,  or 
a  beam  becomes  part  of  a  truss  assembly.  This  "fxinctionality" 
aspect  of  product  definition  will  be  studied  further  in  PDES 
development. 


3.5  Tolerancinq  Application  Area  -  William  C.  Burkett. 

McDonnell  Aircraft  Co.  -  Chairman.  IGES  Manufacturing 

Technology  Subcommittee 

The  PDES  Tolerance  Application  Group  (TAG)  was  formed  in 
response  to  a  request  by  the  Logical  Layer  Initiation  Task  Group 
to  develop  a  reference  model  of  the  information  required  to 
tolerance  a  product  model. 

The  objective  of  the  modeling  effort,  as  defined  by  the  TAG, 
was  to  identify  and  define  the  information  required  to  support 
the  tolerancing  practices  as  advocated  by  the  ANSI  Y14.5M  -  1982 
emd  ISO  1101  and  1660  standards.  In  addition,  the  representation 
of  the  product  was  assiimed  to  be  a  three-dimensional  (3-D) 
geometric  model  rather  than  the  traditional  engineering  drawing. 
Although  the  above  standards  are  oriented  toward  dimensioning  and 
tolerancing  the  pictorial  representation  of  the  product  (the 
drawing) ,  it  was  felt  that  the  concepts  presented  were  equally 
applicable  to  a  3-D  geometric  representation.  The  TAG, 
therefore,  did  not  attempt  to  develop  new  concepts  to  tolerance  a 
3-D  geometric  model,  but  rather  attempted  to  capture  the  concepts 
presented  in  the  standards  and  apply  them  in  a  new  environment. 
This  approach  essentially  is  "a  step  into  the  future  with  a  foot 
firmly  planted  in  the  past." 
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More  specifically,  the  scope  of  the  TAG  work  was  defined  by 
the  information  required  to  tolerance  the  shape  of  a  3-D 
geometric  product  model.  There  are  several  important  assumptions 
that  went  into  the  work: 


-  The  geometric  model  is  a  boundary  representation  solid 
model  or  an  equivalent  surfaced  wireframe  model.  (This  is 
needed  to  address  specific,  discrete  regions  (surfaces) 
of  the  product  model  and  the  corresponding  regions  of  the 
physical  product.) 

-  The  geometric  model  represents  exactly  the  nominal  shape 
of  the  product. 

-  Dimension  information  is  implicit  in  the  model  geometry. 

Outside  the  scope  of  the  TAG  work  were: 

-  Computing  Tolerances 

-  Process  Tolerances 

-  Pictorial  Representation  of  the  Tolerances 

-  Dimensioning  Practices 

-  Non-Mechanical  Tolerances  (e.g.  Electrical  Component 
Values) 

The  reference  model  produced  was  based  on  the  work  done  in 
this  area  by  the  PDDI  project.  In  addition,  the  work  done  by 
R.H.  Johnson  for  CAM-I  (D&T  Final  Report,  R-84-GM-02 . 1)  was 
reviewed.  It  is  felt  that  the  approaches  taken  by  Johnson  and 
that  of  the  TAG  are  not  incompatible,  since  they  differ  primarily 
only  in  depth  and  breath. 


3.6  Finite  Element  Modeling  -  William  R.  Freeman.  Allied 

Bendix  Aerospace.  Kansas  City  Division  -  Member.  IGES  FEM 
Subcommittee 

The  Finite  Element  Method  (FEM) *  is  a  technique  for  creating 
mathematical  models  for  engineering  analysis.  These  analyses  may 
include  stress,  vibration,  heat  transfer,  plastic  molding, 
electrostatics  or  magnetic  fields.  The  FE  method  uses  a  model  of 
the  real  object  divided  into  regular  subdivisions  called 
elements.  These  elements  are  defined  by  points  in  space  called 
nodes.  The  nodes  and  elements,  along  with  additional  information 
such  as  material  properties  makes  up  the  model. 

The  IDEF-1  application  model  created  by  the  IGES/PDES  FEM 
Committee  contains  all  of  the  basic  information  that  is  contained 
in  a  finite  element  model.  The  original  data  required  to  create 
that  model,  such  as  the  shape  (geometry)  of  the  real  object,  the 
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bill  of  materials,  material  properties,  and  the  environmental 
conditions  relating  to  the  analysis  (loads,  temperatures,  etc) 
comes  from  outside  sources  which  are  not  included  as  a  part  of 
the  FEM  application  model. 

FEM  analysis  data  were  not  included  in  the  model.  These  ' 
emalysis  results  are  important,  but  are  logically  separate  from 
the  information  required  to  define  the  model  prior  to  analysis. 
This  partitioning  was  intended  to  match  the  scope  of  the 
application  model  to  the  available  time  and  personnel  resources. 

The  application  model  covers  nodes,  elements,  material 
properties,  environment  (loads,  restraints,  temperature,  etc.), 
grouping  of  entities,  and  their  interrelationships.  ConsideraQsle 
detail  is  included  in  the  data  dictionary,  included  as  a  part  of 
the  model.  The  FEM  Committee  feels  that  the  current  application 
model  fairly  represents  the  data  relationships  necessary  to  fully 
understand  the  Information  and  the  information  relationships 
required  for  a  FE  model,  and  is  therefore  complete.  In  addition, 
the  model  has  been  verified  through  the  use  of  the  "natural 
language  quality  assurance  loop”  which  gives  further  assurance 
that  the  IDEF-1  information  model  correctly  represents 
relationships  between  FE  information  entities. 

Future  plans  include  the  addition  of  analysis  results  to  the 
IDEF'l  model,  and  some  consideration  of  the  sources  of  original 
information  from  which  the  FE  model  is  abstracted.  A  real  part 
may  indeed  be  analyzed  \inder  multiple  environmental  conditions, 
for  a  number  of  analysis  types,  with  alternate  materials,  with 
various  levels  of  detail  resolution,  and  so  on,  but  it  is  still 
the  same  part,  even  when  represented  by  many  different  FE  models. 
At  present,  this  overall  concept  is  difficult  to  properly  place 
in  the  order  of  things,  but  should  be  included  in  the  overall 
electronic  data  system  which  PDES  is  addressing. 

In  summary,  the  FEM  application  model  is  considered  to  be 
complete  (with  the  exception  of  analysis  results) ,  and  correct. 
The  I6ES  FEM  Conmittee  has  verified  and  approved  this  model  for  a 
"draft”  level  of  release  outside  of  the  PDES  working  groups.  Few 
if  any  changes  are  expected,  aside  from  the  extensions  for 
analysis  results. 
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Section  Four 


4.0  Details  Of  Applying  The  Methodolocrv 

4.1  Example  1;  Electrical  Schematic  Application  Model 

4.1.1  Introduction 

This  application  uses  simple  2D  geometric  constrxicts,  is 
compact,  and  exemplifies  the  principles  of  the  methodology.  The 
purpose  of  this  section  is  not  to  review  the  entire  electrical 
model,  but  rather  to  use  the  model  as  a  vehicle  to  review  an 
actual  use  of  the  methodology. 

4.1.2  Review  Of  Phase  1  Of  The  Methodology:  Qualification 

The  documentation  package  as  received  from  the  electrical 
task  group  is  in  Appendix  C4.  This  package  exemplifies  a 
documentation  style  which  is  highly  desirable  from  the  vantage 
point  of  the  Logical  Layer.  We  offer  here  a  condensed  version  of 
the  docxoment  package. 


Strategic  Directions 


SCOPE:  This  document  contains  diagrams  and  text 

representing  a  conceptual  model  of  the  data  required 
to  describe  an  electrical  schematic. 


CONTEXT: 


PURPOSE: 


This  model  identifies  Entities,  Relationships  and 
Attributes  which  are  logically  necessary  to 
construct  an  electrical  schematic.  It  also 
Identifies  some  probable  relationships  to  entities 
in  two  other  applications:  circuit  analysis  and 
printed  circuit  board  physical  design. 

This  model  proposes  portions  of  the  PDES  logical 
layer  required  to  record  an  electrical  schematic  for 
integration  with  other  portions  of  the  PDES  logical 
layer. 


VIEWPOINT:  The  viewpoint  of  this  model  is  that  of  the 

IGES/PDES  electrical  siibcommittee . 


Model  Notes  for  Reviewers 


Inasmuch  as  the  intended  use  of  the  model  is  a  logical  view 
of  the  data,  independent  of  existing  systems  or  methods,  for 
development  of  a  neutral  product  data  exchange  structure,  the 
reviewer  is  asked  to  keep  in  mind  several  important  modeling 
constraints : 
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The  entities  and  attributes  are  to  reflect  the  data  inherent 
in  schematics,  as  opposed  to  the  information  conveyed  by  a 
schematic.  An  example  is  the  \iser  view  preceding  the  logical 
IDEF-1  model  describing  a  netlist.  The  netlist  is  recognized 
here  as  information  assembled  by  a  query  against  schematic  data. 
In  turn,  the  model  must  be  capable  of  supporting  such  a  query. 
Elements  of  information  found  in  the  netlist  eure  found  in  the 
Network,  Symbol  Connection  Place,  and  Symbol  Instance  entity 
classes. 

The  model  must  exist  independent  of  implementation.  The 
entity  classes  in  the  logical  model  must  be  equally  valid  for  a 
pencil-drawn  schematic  or  a  CAE  system  with  model  data 
structures . 

The  author's  opinion  is  also  offered  that,  strictly 
speaking,  an  electrical  schematic  (the  totality  of  this  model)  is 
not  part  of  "product  definition".  Schematics  exist  only  as  a 
design  aid  and  as  reference  documentation. 

Electrical  Schematic  Application  -  User  View 
I .  Definition 

The  schematic  is  a  symbolic  representation  of  component 
parts  and  their  electrical  connections .  The  schematic  may  apply 
to  any  hierarchical  level  of  product  definition,  and  becomes  part 
of  the  packaging  requirements  at  that  level.  Schematics  may  also 
contain  details  of  related  mechanical  nature  (e.g.  heat,  sinks, 
connectors,  etc.)  and  transmission  of  optical,  magnetic  or 
microwave  energy. 

II  Inputs  (sources  of  design  constraints) 

o  Block  diagram,  system  or  sxibsystem  with  target  block 
identified 

o  Interface  requirements  (e.g.,  signals  and  power) 

o  Mechemical  package  requirements  (e.g.,  chip,  hybrid 
microelectronic  assembly  or  printed  board  size  and 
mounting) 

o  Design  (and  product)  constraints  and  characteristics 
(e.g.,  specifications,  system  equations,  test 
requirements) 

o  Schedules  and/or  budget 

o  Approved  (or  preferred)  parts  lists 

o  Symbol  set  and  drafting  standards 
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III  Items  schematic  relates  to  durlrg  design 
o  Design  block  diagreun 

o  Boolean  operators 
o  Detail  eguations/transformations 
o  Static  or  dynemic  models  and  simulations 

IV  Schematic  constituents 

SYMBOLS:  a  2-dimensional  figure  commonly  accepted  as  a 
representation  for  a  part's  ftinctionality. 

SYMBOL  CONNECTION  POINTS:  indicates  where  connections  to 
symbol  can  occur. 

JUNCTION  POINT:  Symbol  (usually  a  filled  small  circle) 
indicating  an  electrical  union  of  2  or  more  connection 
lines. 

CONNECTION  LINES,  SINGLE:  a  2-D  line  or  string  between 
symbol  connection  points  or  junction  points. 

V  Schematic  outputs 

PICTORIAL:  used  to  review  circuit  design  and  as  part  of 
final  product,  documentation. 

NET  LIST:  a  topology  derived  by  exaunining  the  logical 
relations  (links)  created  by  the  connection  lines  (joints) . 

BILL-OF-MATERIALS :  a  list  of  parts  cited  in  schematic. 

Used  stress  analysis,  packaging  the  physical  circuit  and  in 
documentation  parts  lists. 

Glossary 

CONNECTION  GEOMETRY:  Geometry  which  represents  the  logic  of  an 
electrical  joining. 

INTERSECTION  PLACE:  A  place  where  connection  lines  are 
considered  to  be  connected. 

LINE:  A  narrow,  elongated  mark  drawn  or  projected. 

NETWORK:  A  collection  of  places  which  are  defined  to  be  at  the 
same  potential  (aka  Node) . 

SCHEMATIC:  A  symbolic  representation  of  a  function. 
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STRING:  A  piecewise,  continuous  form  of  a  2-D  line  (aka 
polyline) . 

SYMBOL  CONNECTION  PLACE:  The  location  on  a  symbol  where  a 
connection  may  occur. 

SYMBOL  INSTANCE:  The  occurrence  of  a  symbol  on  a  schematic. 


Discussion  Of  Phase  1  Of  The  Methodology 

We  will  describe  the  process  of  translating  the  Discipline 
Model  (figure  4-1)  to  a  Qualified  model.  Normally,  this  process 
starts  by  doing  a  literal  translation  from  the  Discipline  Model. 
This  will  be  a  purely  syntactical  translation  (figure  4-2)  with 
no  regard  for  the  meaning  of  the  objects  in  the  diagram.  The 
main  pu^ose  of  this  first-cut  translation  is  to  expose  detail 
and  verify  any  obvious  key  migration  errors  in  the  IDEF-1 
diagrzuDS.  IDEF-1  places  detail  inside  of  the  object  boxes  NIAM 
places  detail  outside  of  its  object  circles.  We  believe  this 
detail-exposing  process  is  critical  to  the  qualification  process. 
This  mechanical  translation  was  not  possible  in  other  application 
areas  which  did  not  use  IDEF-1  as  the  modeling  language. 

Once  the  literal  translation  is  availaUsle  it  is  used  as  a 
reference  by  the  logical  layer  person  for  learning  the  electrical 
schematic  application.  Our  experience  showed  that  we  were  edsle 
to  ask  questions  to  the  application  expert  directly  from  the  NIAM 
diagr2UBa  and  the  expert  was  able  to  answer  the  questions  by 
examining  only  his  IDEFl  diagram.  There  were  times,  however, 
when  it  was  necessary  for  the  logical  layer  person  to  have  a  good 
knowledge  of  IDEF-1. 

A  specific  technicjue  used  by  the  logical  layer  person  in 
this  specific  ex2unple  was  to  "picture"  (figure  4-3)  what  the 
literal  translation  was  saying.  In  some  cases  the  original  IDEF- 
1  diagrams  lacked  some  precision  in  expressing  concepts 
(translating  literally  to  NIAM  did  not  solve  this  problem) .  In 
those  areas  of  imprecision,  supporting  text  docximentation  was 
extremely  helpful.  It  is  always  more  difficult  to  formally  model 
a  concept  than  it  is  to  casually  express  it  in  natural  language. 
Once  a  picture  is  built,  it  is  compared  to  the  literal  model.  A 
constructive  comment  is  offered  at  this  point:  most  document 
packages  contained  few  pictures  of  concepts.  In  most  cases  the 
logical  layer  person  had  to  build  his  own  pictures  and  validate 
with  the  application  expert. 

A  new  NIAM  model  (figure  4-4)  is  now  constructed  that  agrees 
with  the  picture  and  the  expert  is  asked  to  validate  the  new 
diagram.  This  diagram  is  the  first  version  of  the  qualified 
model.  This  qualified  diagrsun  will  go  through  five  to  seven 
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Iterations  before  conplete  agreesent  between  application  and 
logical  layer  is  achieved. 

In  the  case  of  the  electrical  model,  some  changes  were  made 
to  the  literally-translated  model.  It  was  felt  by  the  logical 
layer  that  the  original  diagram  did  not  precisely  express  the 
content  of  the  picture  in  figure  4-3.  The  constraint  capaJsility 
of  NIAM  was  used  to  add  precision  mostly  through  the  total-role 
and  mutual-exclusion  role  constraints.  (Refer  to  NIAM  primer  in 
Appendix  D2  for  explaination  of  total-role  and  mutual-exclusion 
role  constraints.) 

The  Literal  translation  basically  said  that  Intersection 
Places  and  Symbol  Connection  Places  are  both  hinds  of  Connection 
Places.  But  the  association  between  Intersection  Places  and 
Start/End  Place  and  between  Symbol  Connection  Places  and 
Start/End  Place  was  not  clear.  The  picture  in  the  logical  layer 
person's  mind  is  shown  in  figure  4-3.  The  c[ualified  model 
explicitly  shows  the  above  relationships  and  adds  additional 
constraints.  It  cannot  be  overstressed  how  important  this 
picturing  process  is  as  a  lot  of  the  common  knowledge  that 
application  experts  share  at  application  working  sessions  is  not 
avail2d3le  to  the  logical  layer  person. 


4.1.3  Review  of  Phase  2  Of  The  Methodolocrvt_  .Global 
C_onceptualiaation  _and  Integration 

By  the  time  we  were  ready  to  proceed  with  this  phase,  the 
geometry,  presentation,  and  topology  models  had  been  completed. 

So  the  basic  techni^e  was  to  find  a  way  to  replace  specific 
objects  in  the  qualified  model  with  generic  objects  from  the 
resource  models  (geometry,  presentation,  topology) .  The  notion 
of  Place  already  existed  in  the  geometry  schema  so  it  was  used. 
Place  appears  only  once  in  the  global  model  instead  of  four  times 
as  in  the  qualified  model.  The  four  occurrences  of  place  were 
replaced  by  a  single  occurrence  of  Place  and  three  new  roles. 
These  roles  are  expressed  in  the  following  four  sentences  derived 
from  the  global  model: 

Place2  is  location  of  Symbol  Connection. 

Place2  is  location  of  Intersection. 

Place2  is  end  of  curve  segment. 

Place2  is  start  of  curve  segment. 

The  edge-vertex  portion  of  the  topology  model  is  used  to 
model  connectivity  explicitly.  In  the  qualified  model,  there  is 
no  mechanism  for  explicitly  showing  connectivity  within  the  model 
unless  it  is  1)  implicitly  assumed  through  symbolic  sharing  by 
Connection  Geometry  of  a  common  geometric  Place  or  2)  a  rule  that 
states  "any  start  or  end  places  that  are  located  within  delta  x 
of  each  other  are  to  be  considered  connected".  This  is  the  rule 
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the  human  would  use  in  looking  at  a  schematic.  In  most  cases  it 
is  possible  to  visually  determine  that  the  start  and  end  places 
actually  touch  and  are  therefore  considered  to  be  connected.  The 
computer  has  no  visual  image  of  touching.  The  main  purpose  of 
the  global  model  is  to  give  the  computer  explicit  "touching" 
information  through  the  Geometry^topology  associativities  Edge- 
curve  and  Vertex-place  A  picture  of  explicit  connectivity  is 
shown  in  figure  4-5. 

The  fundeunental  test  that  must  be  run  against  the  new  global 
schema  (figure  4-6}  is:  can  a  (juery  be  run  against  the  new 
schema  to  create  a  net  list?  Casual  exaunination  of  the  global 
schema  should  confirm  this.  We  do  not  have  any  thorough  way  of 
determining  formally  whether  or  not  the  qualified  schema  and 
global  schema  are  equivalent. 

As  stated  in  the  methodology  description,  integration  is  the 
act  of  reconciling  the  qualified  model  with  the  global  model.  We 
will  attempt  to  do  that  in  English  as  we  have  no  formal  mapping 
language.  The  general  form  of  each  reconciliation  statement  will 
be  "X  in  qualified  model  is  replaced  by  Y  in  global  model."  For 
exeunple: 

The  sentence  "Connection  Geometry  has  Start  Place"  in 
qualified  model  is  replaced  by  the  sentence  "Edge-curve  has 
connection  line  defined  by  Composite  Segment?  that  is 
composed  of  Curve  Segment?  with  start  place  defined 
by  Place?"  in  the  global  model.  We  ask  ourselves  "Is  this 
a  valid -sentence  replacement?".  If  it  is  we  have  a 
successful  instance  of  reconciliation. 

It  should  be  mentioned  here  that  new  connectivity 
information  has  been  added  in  translation  to  the  Global  model. 

A  critical  issue  here  is  whether  or  not  to  allow  additions  to  be 
made  to  the  qualified  schema  when  converting  it  to  global  form  as 
this  confuses  the  process  of  reconciliation.  Realistically  this 
will  probedaly  happen  as  the  logical  layer  person  perceives  a 
complete  way  of  expressing  application  semantics.  Once  this 
discovery  is  made,  a  decision  must  be  made  to  go  back  and  make 
the  c[ualified  model  complete.  In  the  case  of  the  electrical 
model,  the  qualified  model  was  not  upgraded  because  of  schedule 
pressures . 

Here  are  the  most  interesting  things  that  one  can  discover 
from  reviewing  the  global  model  (particularly  figure  4-7  which 
shows  the  substitution  by  geometry,  presentation,  and  topology) : 

1.  A  large  portion  of  the  qualified  model  was  replaced  by 
objects  and  structures  from  the  resource  models. 

« 
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2.  Many  objects  in  the  qualified  model  have  been  replaced  by 
associativities  in  the  global  model.  These 
associativities  act  like  "glue"  to  tie  together  fragments 
of  the  resoxirce  model. 

3.  Because  the  global  model  uses  more  general  structures,  it 
tends  to  have  more  objects. 

4.  The  global  model  removes  objects  and  adds  new  roles. 

5.  The  resource  object  "Vertex-place"  replaces  both 
Intersection  place  and  Symbol  connection  place. 

6.  The  global  schema  is  modular.  Associativities  tie  the 
modules  together. 

4.1.4  Review  Of  Phase  3  Of  The  Methodology;  Specification 

Specification  was  broken  into  two  basic  steps:  1)  grouping 
of  the  Global  model  emd  2)  translation  of  the  groups  into  DSL. 

The  grouping  process  was  a  joint  effort  between  the  builder  of 
the  global  model  and  the  DSL  specifier.  The  groupings  were  based 
on  the  notion  of  defining  relationships  (figure  4-6).  For 
example  one  group  might  be  the  association  between  Network  and 
Edge-curve.  Since  the  Global  model  says  that  a  Network  is 
composed  of  (defined  by)  many  Edge-curves,  this  seems  like  a 
natural  grouping. 

Here  are  more  specific  examples  of  groups: 

Edge-curve  has  connection  line  defined  by 
Composite  Segment2  and  also  is  foundation  for  an 
Edge.  (  Note  that  the  notion  of  defining  relationship  is 
somewhat  artificial  with  associativities.) 

Edge  has  start  vertex.  Edge  has  end  vertex. 

(this  is  the  normal  Geometry-topology  associativity) 

Curve  Segment2  has  start  Place2.  Curve  Segment2  has  stop 
Place2.  (this  is  the  normal  Geometry  structure) 

Vertex-place  at  Vertex  and  Vertex-place  is  located  at 
Place2.  (This  is  the  normal  Geometry- topology  associativity 
structure  -  however,  sufficient  information  has  not  been 
added  to  indicate  that  Vertex-place  is  playing 
the  role  of  Symbol  connection  place.  Note  also  that 
Vertex-place  plays  the  role  of  being  Intersection  place. 

The  orignal  discipline  model  is  almost  unrecognizable  in 
the  Global  model.  It  is  important  that  we  see  an  instance 
of  a  nearly  "all-generic"  Global  model  to  see  the  importance 
of  a  mapping  from  Discipline  model  to  Global  model. 
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We  have  attempted  to  group  based  on  ^e  loose  notion  of 
"defining  relationship".  We  realize  that  some  groupings  may 

be  more  difficult  as  the  notion  of  definition  is  not  as  strong. 

An  associativity  is  something  that  has  definition  but  the  notion 
of  definition  relationship  is  not  so  clear  with  abstract  objects 
such  as  associativites .  Does  it  medce  sense  to  say  that  Vertex- 
place  is  defined  by  a  Place2  and  a  vertex?  It  does  not  sound 
quite  right.  There  is  some  question  as  to  whether  the  notion  of 
defining  relationship  can  be  clearly  defined  itself.  Grouping 
will  be  an  on-going  problem  that  we  must  face  if  we  are  to 
present  the  PDES  in  a  concise  easy-to-read  form  that  abstracts 
out  detail.  Complexity  is  the  real  problem  we  are  dealing  with 
and  the  need  for  abstraction  techniques  is  critical.  Grouping  is 
an  abstraction  technique.  The  Version  1.0  effort  must  come  to  an 
agreement  on  a  grouping  rationale. 

Here  is  a  sample  DSL  of  the  groupings  in  figure  4-8. 

ENTITY  network; 

ROLE 

component  :LIST  (1  to  *)  OF 

REFER  (edge_curve) ; 

END; 


ENTITY  edge  curve; 

ROLE 

geometry  : REFER  ( compos ite_segment_2) ; 
topology  : REFER  (edge) ; 

END; 


Model 

4.2. 1  Introduction 

The  Logical  Layer  Group  focused  its  attention  on  a  specific 
application  for  its  first  attempt  at  exercising  the  methodology. 
The  application  chosen  was  the  design  of  flat  plate  with  holes. 
This  application  was  purposely  kept  simple  and  based  on  the 
difficulty  we  had  in  modeling  this  application,  it  was  a  wise 
decision.  As  a  result  of  this  experience  we  are  convinced  that 
the  principle  of  pushing  specification  applications  through  a 
methodology  is  a  good  test  scheme.  This  kind  of  test  is 
distinctly  different  from  using  a  broad  application  area  as  a 
test.  The  knowledge  area  is  very  specific  and  limited,  which 
reduces  modeling  time. 

4.2.2  Review  Of  Phase  1  of  the  Methodolocrvt  Qualification 

The  complete  dociimentation  package  received  from  the  Flat 
Plate  application  group  task  group  is  contained  in  Appendix  C3. 
This  package  clearly  spelled  out  the  scope  and  definition  of  the 
application.  Our  final  model  did  not  cover  the  entire  area 
defined  by  the  documentation  package  because  of  schedule 
pressures.  Roughly,  it  covered  the  left  half  of  the  discipline 
model  given  in  figure  4-9.  For  purposes  of  exposition,  we  offer 
a  condensed  version  of  the  document  package. 

Scope  of  the  Model 

For  the  purposes  of  this  initial  document,  flat  plates  are 
considered  to  have  the  following  characteristics: 

-  Plate  has  two  major  (large)  faces,  a  top  and  a  bottom 

-  Uniform  thickness;  i.e.,  top  and  bottom  faces  are 
parallel . 

-  The  top  and  bottom  faces  are  not  required  to  have 
congruent  dimensions  (this  requirement  was  changed  later 
to  require  congruent  dimensions  in  order  to  simplify  the 
model) . 

-  The  thickness  is  small  relative  to  the  top  and  bottom 
face  dimensions. 

-  For  any  traverse  from  top  to  bottom  face,  along  the 
intersection  of  an  arbitrary  plane  perpendicular  to  the 
top  and  bottom  faces,  only  one  "side  face"  will  be 
encountered . 
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-  Only  round,  through  holes  of  uniform  diameter  are 
allowed.  (This  requirement  was  later  relaxed  as  it  was 
just  as  easy  to  allow  for  holes  of  arbitrary  shape  and 
depth) . 

-  Edge  conditions,  e.g.  chamfer/radius  specifications  will 
be  treated  as  attributes.  If  the  chamfers/ radii  are 
large  enough  to  require  more  detailed  definition,  they 
are  outside  the  scope  of  this  model.  (Again,  this 
requirement  is  somewhat  relaxed  by  allowing  the  perimeter 
of  the  flat  plate  to  be  any  closed  planar  shape  with  not 
self-intersections) . 


Definitions 


Flat  Plate 

This  is  an  entity  that  is  the  "top  of  the  tree"  in  the 
definition  of  a  single  piece  part.  All  the  definitional 
information  for  the  part  is  under  this  entity. 

Face 


Face  is  a  topological  entity.  It  is  essentially  a  bounded 
surface.  The  boundaries  are  topological  entities,  edges,  with 
their  end  points  defined  by  vertices.  This  is  the  relatively 
standard  B-RZP  notation. 

Surface 

The  geometric  (mathematical)  entity  that  defines  the  shape 
of  a  face. 

Datum 


One  of  three  planes  that  in  principle  define  the  coordinate 
system  of  the  plate.  The  three  planes  are  mutually  perpendicular 
and  intersect  in  a  point.  That  point  is  the  origin.  The  planes 
or  some  manifestation  of  them  are  referenced  as  datxims  in 
tolerances  and  other  entities. 

Angular  +  Location  +  Geometric  tolerances 

These  tolerances  are  defined  in  the  tolerance  model.  Their 
presence  in  this  model  is  to  indicate  the  relationships  of 
tolerances  to  the  flat  plate  part. 
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Edge 


The  topological  entity  that  bounds  a  face.  It  is 
essentially  a  geometric  curve,  bounded  by  end  points  (vertices) . 

Curve 


The  geometric  (mathematical)  entity  that  defines  the  shape 
of  an  edge. 

Vertex 

The  topological  entity  that  bounds  an  edge.  It  is 
essentially  a  geometric  point. 

Coordinate  Point 

The  geometric  (mathematical)  entity  that  defines  a  location 
in  space. 

Hole 


A  feature  of  the  flat  plate.  It  is  defined  by  its  diameter, 
centering  vector,  and  a  coordinate  point  contained  on  a  surface 
of  the  plate.  This  feature  entity  may  be  required,  in  some 
applications,  to  be  transformed  into  topology  and  geometry,  e.g., 
an  assortment  of  faces  and  edges,  but  for  purposes  of  model 
definition,  this  definition  is  informationally  complete  within 
the  scope  of  the  model. 

Surface  texture 

This  is  an  entity  that  describes  the  allowedsle  deviation 
from  perfection  (at  the  micro  level)  of  a  surface.  The  exact 
definition  is  given  by  ANSI  and  ISO  standards. 

Vector 

A  geometric  (mathematical)  entity  that  defines  a  direction 
in  space. 

Size  tolerance 

One  of  the  tolerance  entities  that  applies  to  the  diameter 
of  a  hole  feature. 

Discussion  of  Phase  1  of  the  Methodology 

The  flat  plate  discipline  model  (left  half)  was  completed  in 
an  extended  version  of  IDEF-1  as  shown  in  figure  4-9.  The 
following  objects  were  excluded  from  the  discipline  model:  heat 
treat  specifications,  drawing  identification,  process  plan 
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identification,  cross  section  view,  profile  view,  3D  view, 
process  instructions  and  configuration  management.  The  qualified 
model  in  figure  4-10  is  a  literal  translation  of  the  left  hand 
side  of  the  discipline  model  in  figure  4-9. 

This  model  caused  us  to  become  aware  of  an  issue  that  may 
occur  in  follow  on  PDES  efforts:  What  kinds  of  objects  would  we 
expect  an  application  expert  to  place  in  a  discipline  diagram? 
Will  they  be  high-level  engineering  objects  like  form  features  or 
will  they  be  foundational  objects  like  vertex,  edge,  curve? 

The  qualification  process  started  by  making  a  literal 
translation  of  the  discipline  model  (left  side)  into  NIAM.  The 
main  purpose  of  such  a  first-cut  translation  is  to  expose  detail 
and  verify  any  obvious  key  migration  errors  in  the  discipline 
IDEF-1  diagram.  In  the  case  of  the  flat  plate  model  there  was 
little  attribute  and  key  information  inside  the  entity  boxes. 

This  literal  translation  was  accepted  as  the  qualified  model  with 
the  following  simplifying  ass\imptions  added: 

1.  Top  and  bottom  faces  are  required  to  be  congruent 
perimeters . 

2.  All  holes  are  perpendicular  to  top  of  flat  plate. 

3.  Non-through  holes  are  not  allowed. 

4.  Any  arbitrary  flat-plate  outline  is  allowed. 

5.  Any  shape  hole  is  allowed. 

It  was  felt  by  the  logical  layer  that  this  qualified  model 
captured  enough  aspects  of  the  application  to  test  the 
methodology. 

4.2.3  Review  of  Phase  2  of  the  Methodology;  Global 
Connceptualization  and  Integration 

Ideally,  the  global  cognitive  model  (figure  4-11)  would  not 
be  a  reconceptualization  of  the  qualified  model.  In  order  to 
link  this  model  to  the  only  resource  model  we  had  at  the  time 
(geometry) ,  the  qualified  model  was  significantly  expanded  to 
include  form  features.  We  believed  that  in  the  initiation  effort 
we  could  have  this  kind  of  license  in  order  to  test  the 
methodology,  but  in  follow-on  efforts,  the  amount  of  new  meaning 
that  is  added  to  any  qualified  model  must  be  carefully 
controlled.  The  primary  duty  of  the  logical  layer  is  to  convert 
the  qualified  model  into  a  global  form.  We  think  a  basic  problem 
in  this  part  of  the  intiation  effort  was  that  we  were  struggling 
to  model  this  application  with  the  limited  conceptual  resources 
at  hand  (wireframe  geometry  only) .  Later,  there  was  no  attempt 
to  update  the  original  qualified  model  as  a  result  of  additional 
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resource  meaning  (e.g.,  topology)  added  to  the  global  model. 
Again,  this  should  not  be  the  case  in  future  efforts. 

The  good  that  really  came  out  of  the  flat  plate  effort  was 
that  we  witnessed  the  evolution  of  a  model.  We  think  this  is 
probably  a  typical  real-world  situation.  Models  don't  just  get 
built,  they  seem  to  evolve.  Because  we  had  only  the  geometry 
resource  to  start  with,  the  flat  plate  model  started  out  as  a 
feature-based  model  with  no  explicit  surfaces  (we  had  no  boundary 
model) .  Later  in  the  project,  a  provisional  tolerance  model  was 
created  and  became  another  resource  for  us.  The  global  model 
then  was  incrementally  modified  to  add  explicit  surfaces  with 
surface  attributes.  This  was  done  with  little  change  to  the 
form-feature  part  of  the  model. 

A  discussion  of  the  changes  to  the  qualified  model  follows: 

1.  The  object  "uniform  thick  profile"  is  added.  This  becomes 
the  basic  definitional  object  for  the  flat  plate  (instead 
of  the  explicit  faces.) 

2.  The  object  "hole"  is  generalized  to  the  object  "uniform 
depression" . 

3.  "Uniform  depression"  is  in  turn  defined  by  "uniform  thick 
profile"  through  the  role  "is  negative  body  for".  Note 
that  the  role  of  "uniform  thick  profile"  for  the  flat  plate 
body  is  "is  positive  "body  for". 

4.  The  association  object  "flat  plate  uniform  depression"  is 
added  to  associate  a  particular  uniform  depression  with  a 
particular  flat  plate  (and  a  composite  model  transform  to 
position  it) . 

5.  The  object  "planar  profile"  is  added  to  link  "uniform  thick 
profile"  with  the  resource  geometry  at  hand. 

6.  The  object  "face"  in  the  qualified  model  is  converted  to 
"side(s)",  "top",  and  "bottom".  A  relationship  between 
"flat  plate  uniform  depression"  and  "side"  is  added  to 
indicate  internal  sides  of  the  hole. 

7.  The  object  "Face-Surface"  is  added.  This  is  a  new  resource 
object  developed  later  in  the  initiation  effort.  Its 
purpose  is  to  separate  geometry  and  topology  so  that  they 
can  have  independent  existence.  "Face  surface"  is  eunong  a 
class  of  resource  objects  called  "Geometry-topology 
associativities"  but  originally  were  called  "Primitive 
Shape  Elements".  We  recognize  that  none  of  these  are  good 
names . 
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8. 


All  surface  references  are  now  directed  to  the  object  "face 
surface".  No  surface  property  will  be  referred  to  either 
geometry  by  itself  or  topology  by  itself. 

These  changes,  many  of  which  involve  additions  or 
generalizations,  indicate  that  the  logical  layer  actually  stepped 
beyond  its  legitimate  bounds  in  this  part  of  the  methodology. 
Phase  2  of  the  methodology  should  not  normally  result  in 
additions  to  the  qualified  model. 

Actually,  the  phenomenon  of  the  continuation  of  discipline 
modeling  on  into  the  qualification  and  the  Global 
conceptualization  and  integration  phases  occurred  across  most 
areas  of  the  initiation  work. 

The  global  model  presented  here  was  a  teem  effort  involving 
engineers,  form  feature  experts,  and  information  modelers.  This 
model  is  the  fifth  iteration. 

4.2.4  Review  of  Phase  3  of  the  Methodolocrv;  Specification 

Unfortunately,  there  was  not  agreement  (between  the  people 
responsible  for  the  global  model  and  the  people  responsible  for 
the  specification  model)  on  the  content  of  the  global  model. 
Figure  4*12  shows  a  possible  grouping  of  the  global  model  in 
preparation  for  specification.  Here  is  a  sample  of  DSL  that 
corresponds  to  part  of  that  grouping: 


ENTITY  flat_plate; 
ROLE 


pos__bod 

holes 

top 

bottom 

side 

END; 


: REFER  (uniform_thick__prof  ile)  ; 

•.LIST  (1  to  *)  OF 

REFER  (flat_plate_uniform__depression)  ; 
:  REFER  top ;  ~ 

: REFER  bottom; 

:LIST  (1  to  *)  OF  REFER  side; 


ENTITY  uniform_thick_profile; 

ROLE 

thic)cness  :t_magnitude; 
out_line  ; REFER  Planar_j5rof ile; 

END; 


45 


ENTITY  f lat_plate_vmi£onn_depression ; 

ROLE 

depression  :  REFER  iJLnifom_depression; 

transform  : REFER  composite_model_transform; 

END; 


ENTITY  ;iniform_depression; 

ROLE 

neg_body  : REFER  xiniform_thick_profile; 

END; 


4.3  Example  3;  Tolerancing  Application  Model 


4.3.1  Introduction 

This  was  a  very  challenging  application  to  model  because  of 
its  bulk.  We  did,  however,  find  a  similar  pattern  eunong  the 
various  tolerances  defined  in  ANSI  Y14.5M-1982  which  accelerated 
our  efforts.  This  was  a  good  application  for  global  modeling  as 
the  tolerance  application  makes  heavy  reference  to  geometry  and 
topology  and  associations  between  them. 

4.3.2  Review  of  Phase  1  of  the  Methodolocrv;  Qualification 

The  documentation  package  received  from  the  toleremcing 
application  group  is  in  Appendix  C5  .  For  the  purpose  of 
exposition  we  offer  here  a  condensed  version  of  the  document 
package. 


Scope 

This  docxment  provides  the  definition  of  fxinctional  content 
for  tolerancing  practices  as  specified  by  ANSI  Y14.5M'-'1982  and 
ISO  1101  and  1660.  These  specifications  are  considered  to  be 
functionally  identical  for  the  purposes  of  this  effoxrt. 

This  information  model  is  intended  to  completely  define  all 
tolerance  information  specified  by  ANSI  Y14.5M-1982  and  the 
corresponding  ISO  specifications. 

Excluded  from  Scope 


'Computing  tolerances 
Process  tolerances 

Pictorial  representation  of  tolerances 
Dimensioning  practices 

Non-mechanical  part  toleramces  (e.g.  electrical  component 
values) 


Assumptions 

Product  models  are  assumed  to  be  3D  wireframe  with 
surfaces. 

Models  contain  exact  definitions  of  nominal  product 
geometry . 

Topology  constructs,  where  used  in  this  model  are  included 
to  satisfy  the  functional  requirements  of  tolerancing.  since  a 
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completely  surfaced  wireframe  and  a  B-REP  model  are  essentially 
equivalent,  we  have  adopted  the  B-REP  terminology  of  face,  edge 
and  vertex  in  our  tolerance  model. 

General  Definitions 

Product:  An  item(s)  which  is (are)  manufactured,  or  used  in  the 
manufacture  of  another  item. 

Model:  A  digital  definition  of  a  product. 

Drawing:  A  pictorial  representation  of  a  product. 

Dimension:  A  numerical  value,  implicit  in  the  model  geometry, 
which  is  a  measure  of  the  product. 

Sximmary  Of  Entity  Types 


100  Geometry 

unit  vector,  point  vector,  vector,  curve,  coordinate,  point 

200  Topology 

vertex,  edge,  face 

300  Feature 

datum,  conditioned  dat\m,  feature  of  size,  form  feature, 
face,  edge,  vertex 

400  Tolerance 

Coordinate  tolerance:  angle  tolerance,  location  tolerance, 
size  tolerance 

Geometric  tolerance:  angularity,  circular  runout, 
circularity,  concentricity,  cylindricity,  flatness, 
parall  lelism,  perpendicularity,  position,  profile  of  a  line, 
prof:le  of  a  surface,  straightness,  total  runout 

Discipline  Model  Examples 

Location  Tolerance  Entity  (403) :  Allowable  deviation  of  a  measure 
of  a  feature  from  its  design  nominal  position  relative  to  a 
specific  base  location  along  a  specified  path  (figure  4-13) . 


Start_entity 

Origin 

Path 

Basic 

Plus-tol 

Minus_tol 

End-entity 


:  Location_origin  (503) 

: Optional  Location_path  (504) 

:  Array  (1  to  maxint)  of 

Location_toleranced_entity  (502) 
: Boolean 
:Real 
:Real 
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mar  ‘d  (i  1986 


Attribute  descriptions: 


Origin:  An  entity  that  serves  as  the  base  or  origin  of  a 
calculated  dimension.  It  is  the  "from"  entity  of  the  directed 
dimension. 

Path:  A  curve  along  which  (or  in  the  direction  of  which)  the 
dimension  is  measured. 

Toleranced_entity :  An  array  of  entities  to  which  the  tolerance 
applies. 

Basic:  A  boolean  (true/ false)  flag  that  indicates  whether  the 
entity  is  used  as  a  BASIC  dimension. 

Plus__tol:  The  eUDsolute  value  of  the  tolerance  that  is  added  to 
the  nominal  dimension  value  to  estaiblish  the  maximum  allowable 
deviation  of  the  toleramced  entity  from  the  nominal. 

Minus_tol:  The  absolute  value  of  the  tolerance  that  is 
si^tracted  from  the  nominal  dimension  value  to  establish  the 
minimum  allowable  deviation  of  the  toleranced  entity  from  the 
nominal . 

Location  Toleranced  Entity  (502):  Location  toleranced  entity  is 
a  location  coordinate  and  a  meaiber  from  the  class  of  edge  (202)  , 
face  (203),  location  tolerance  qualified  form  feature  (533), 
feature  of  size  (303),  vertex  (201).  See  figure  4-14. 

Start_entity 
Toleranced_entity 


Toleranced_location 
End_entity; 

Attribute  Descriptions : 

Toleranced_entity:  An  entity  to  which  the  tolerance  applies. 

Toleranced_location:  A  coordinate  which  specifies  the  reference 
location  on  the  toleranced  entity.  The  coordinate  must  lie  on 
the  toleranced  entity. 

Location  Origin  Entity  (503): 


:Face,  edge,  vertex,  feature^of 
size,  or  location_tolerance_ 
qualified_form_feature 
:  Coordinate  (107) 
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Location  origin  is  eui  origin  coordinate  and  a  nenber  from 
the  class  edge  (202),  face  (203),  datinn  (301),  vertex  (201).  See 
figure  4-15. 

Start_entity 

Origin_entity  :Face,  edge,  vertex  or  datum 

Origin_location  : Coordinate  (107) 

End_entity ; 

Attribute  Descriptions: 

Origin_entity:  An  entity  that  serves  as  the  base  of  the 
calculated  dimension.  It  is  the  ''from”  entity  of  the  directed 
dimension. 

Origin_location:  A  coordinate  which  specifies  the  base  position. 
The  coordinate  must  lie  on  the  origin  entity. 

Location  Path  Entity  (504) :  A  location  path  is  a  class  of 
entities.  The  class  is  used  to  specify  the  path  along  which  a 
dimension  measure  is  calculated.  A  curve  instance  must  contain 
but  necessarily  end  with  the  toleranced  coordinate  point ( s) .  See 
figure  4-16. 

Class  of  :unit_vector  (101) 
curve  (105) 

End_class ; 

Discussion  of  Phase  1  of  the  Methodology 

From  the  vantage  point  of  the  logical  layer  this  was  a  very 
complete  and  precise  docximent  that  was  at  first  overwhelming  in 
its  content.  This  document  contained  both  IDEF-1  (extended) 
diagrams  and  a  Pascal-like  (similar  to  DSL)  language  of  the 
tolerance  model.  We  foxind  that  the  IDEF-1  diagreu&s  served  as  a 
guide  to  the  entire  model,  whereas  the  Pascal-like  specification 
seemed  to  be  the  focus  of  the  document's  precision. 

Our  liaison  sessions  were  very  intense.  Two  tolerance 
application  persons  acted  as  liaison  in  a  visit  to  the  logical 
layer  liaison  session.  NIAH  was  used  as  the  primary 
commiinication  tool  between  tolerance  liaison  and  logical  layer, 
so  in  affect  the  translation  was  being  done  "live”. 

The  qualified  model  covers  almost  all  of  the  content  of  the 
document.  Geometry  and  topology  were  modeled  even  though  these 
models  existed  externally  as  a  resource  models.  It  was  necessary 
to  get  the  application  view  of  geometry  and  topology  in  order  to 
determine  that  the  resource  models  were  satisfactory. 

We  feel  that,  for  tJhe  most  part,  this  instance  of 
qualification  was  indeed  a  translation  from  the  application 
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language  and  not  merely  a  reconceptualization  of  the  application 
area.  There  were  a  few  tines  when  the  logical  layer  referred 
directly  to  the  ANSI  Y14.5M  document  for  resolution  of  meaning. 

Figure  4-17  is  the  qualified  NIAM  model  corresponding  to  the 
above  Location  Tolerance  (403).  The  translation  from  the 
Pascal_like  syntax  to  NIAM  was  not  mechanical.  The  two  liaison 
persons  participated  heavily  in  this  translation  and  in  fact 
learned  to  read  NIAM  diagrams  in  order  to  perform  their  fxinction. 
This  is  an  ideal  situation  but  one  we  do  not  expect  to  encov.nter 
in  all  application  areas.  We  will  probzdDly  be  fortiinate  to  have 
application  experts  fluent  in  one  modeling  language.  However,  we 
could  not  have  achieved  the  translation  in  the  time  permitted  by 
the  schedules  without  the  application  experts  having  a  reading 
knowledge  of  NIAM. 

4.3.3  Review  of  Phase  2  of  the  Methodology:  Global 
Conceptualization  and  Integration 

The  process  of  building  the  global  model  (figure  4-18)  was  a 
straight  forward  process  of  identifying  objects  in  the  qualified 
model  that  had  corresponding  objects  in  the  resource  models.  As 
a  result  of  building  this  global  model,  a  new  resource  model  was 
created.  This  new  resource  model  is  called  "Primitive  shape 
elements"  (figure  4-19) .  This  new  model  was  created  in  order  to 
keep  geometry  and  topology  as  independent  resource  models.  This 
model  is  a  set  of  associativities  between  geometry  and  topology. 
Often  models  will  refer  to  topology  and  then  topology  will  refer 
to  geometry  (or  does  geometry  refer  to  topology?) .  The 
"Primitive  shape  elements"  model  puts  geometry  on  the  same  level 
as  topology  (one  is  not  stibordinate  to  the  other).  The  principal 
objects  in  this  model  are:  face-surface,  edge-curve,  and  vertex- 
point.  This  model  probably  should  be  reneuned  as  "primitive  shape 
elements"  is  probably  already  used  in  many  other  contexts.  We 
considered  calling  it  GTA  for  geometry-topology  associativity. 

The  following  is  a  summary  of  substitutions  that  were  made 
to  the  qualified  model  to  guild  the  global  model: 

1.  Face  is  replaced  by  Face-surface.  (Primitive  shape 
elements) . 

2.  Edge  is  replaced  by  Edge-curve.  (Primitive  shape 
elements) . 

3.  Vertex  is  replaced  by  Vertex-point.  (Primitive  shape 
elements) . 

4.  Coordinate  is  replaced  by  Place  (Geometry). 

5.  Unit  vector  replaced  by  Direction  (Geometry) . 

6.  Topology  replaced  by  Primitive  shape  elements. 
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AttK.  ot  ^'1^:^:4:,,»  S^m/rn 


A  new  resource  model  called  "Feature”  was  considered  but  was 
not  followed  because  it  represented  a  new  arena  of  modeling 
problems.  We  do  think,  however,  that  there  should  someday  exist 
a  feature  resource  model. 
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Example  4t  Finite  Element  Modeling  Application  Model 

4.4.1  Introduction 

The  FEM  discipline  model  represents  a  significant  team 
effort  in  accjuiring  the  conceptually  modeled  FEM  knowledge.  The 
FEM  teeua  had  as  an  objective  the  creation  of  a  single  model  broad 
enough  to  accommodate  emy  major  FEM  application.  This  model  was 
particularly  useful  to  the  initiation  effort  because  it  became 
stable  very  early  in  the  project.  This  allowed  the  logical  layer 
to  really  do  its  job  of  validation  and  global  conceptualization. 
See  Appendix  C6  for  complete  model. 

4.4.2  Review  of  Phase  1  of  the  Methodolocfv:  Qualification 

The  discipline  model  is  shown  in  figure  4-20.  The  basic 
application  documentation  consists  of  a  single  lDEF-1  diagram 
and  a  definition  of  terms.  Based  on  this  documentation  the 
logical  layer  was  edale  to  iinderstand  most  of  the  application  area 
with  the  exception  of  the  FEM  notion  of  connectivity  which 
required  additional  liaison  with  the  application  experts.  We 
were  most  fortunate  that  the  FEM  liaison  person  was  employed  by 
the  same  company  as  the  principal  logical  layer  worker.  We  were 
also  fort\inate  that  this  model  matured  quite  early  so  that  the 
qualification  process  did  not  involve  any  extensive  remodeling 
but  rather  concentrated  on  the  validation  process.  While 
validating  this  model,  extensive  work  was  done  in  developing 
translation  from  IDEF-1  to  NIAM.  The  qualification  process 
involved  the  derivation  of  natural  language  sentences  from  the 
original  lDEF-1  diagrams.  These  sentences  resulted  in 
adjustments  to  the  model. 

The  model  appeared  to  be  too  simple  when  it  was  first  viewed 
by  the  logical  layer.  We  were  expecting  a  much  larger  model. 

What  we  had  expected  to  see  was  an  enumeration  of  many  specific 
types  of  FEM  elements.  What  we  found  was  a  very  general  model 
that  would  allow  for  any  kind  of  FEM  structure. 

For  the  purposes  of  exposition,  we  offer  here  a  condensed 
version  of  the  FEM  dociiment  package. 

Scope 

The  model  contains  objects  and  relationships  to  accommodate 
all  FEM  elements  types  and  all  major  FEM  applications. 

Definitions 

Connectivity:  the  assignment  of  a  node  to  an  element.  This 
refers  to  a  single  occurence  of  this  cross  reference  (CR) ,  not  a 
list  of  all  the  multiple  occurrences  of  this  entity. 
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Coordination  system:  a  fraune  of  reference  used  to  define  the 
location  of  a  finite  element  model  or  its  components  into  3D 
space. 

Element:  the  basic  model  building  block  defining  the 
relationship  between  its  nodes. 

Element/geometric  property:  assignment  of  a  geometric  property 
to  an  element.  This  refers  to  a  single  occurence  of  this  cross 
reference  (CR) ,  not  a  list  of  all  the  multiple  occurrences  of 
this  entity. 

Element  order:  the  mathematical  definition  for  the  allowable 
deformation  of  an  element.  An  element  with  nodes  only  at  comers 
is  a  linear  or  first  order  element,  emd  may  undergo  only  linear 
deformation.  An  element  with  an  additional  node  on  each  edge 
between  comer  nodes  is  a  paredsolic  or  second  order  element.  The 
order  equals  the  number  of  non-comer  nodes  per  element  edge  plus 
one.  The  element  order  and  the  element  shape  together  imply  an 
expected  nximber  of  nodes  to  define  the  element.  Missing  nodes 
are  caused  by  transition  elements,  and  excess  nodes  imply  face- 
located  nodes. 

Environment:  any  external  or  internal  influence  on  a  finite 
element  model. 

Environment/ group  cross  reference:  assignment  of  an  environment 
to  a  group.  This  refers  to  a  single  occurence  of  this  cross 
reference  (CR),  not  a  list  of  all  the  multiple  occurrences  of 
this  entity. 

Geometric  property:  values  that  may  be  used  to  describe  the 
physical  characteristics  of  an  element.  For  example,  shell 
element  thickness,  beam  element  area  moment  of  inertia,  etc. 

Group:  a  collection  of  model  nodes,  model  elements  or  FEM 
environments  or  emy  combination  thereof. 

Material  Property:  values  that  may  be  used  to  describe  the 
constitutive  nature  of  an  element  or  a  node. 

Node:  a  location  in  a  finite  element  model;  used  to  define 
elements  and  environments. 

Node/coordinate  system  cross  reference:  the  assignment  of  a 
coordinate  system  to  a  model  node.  This  refers  to  a  single 
occurence  of  this  cross  reference,  not  a  list  of  all  the  multiple 
occurrences  of  this  entity. 
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Node/ environment  cross  reference:  the  assignment  of  an 
environment  to  a  node.  This  refers  to  a  single  occxirence  of  this 
cross  reference,  not  a  list  of  all  the  multiple  occurrences  of 
this  entity. 

Node  sequence  number:  the  nvtmber  which  represents  the  position 
of  a  node  in  an  ordered  list  of  nodes  which  defines  an  element, 
(the  connectivity  list) .  A  single  instance  of  the  connectivity 
CR  entity  will  use  this  sequence  number  to  cross  reference  a  node 
with  a  particular  location  on  a  particular  element. 

Origin:  the  position  in  a  coordinate  system  with  all  zero 
coordinate  values. 

Transformation  matrix:  the  matrix  used  to  specify  the 
orientation  euid  location  of  an  entity  in  space,  as  well  as  the 
scale  of  the  entity. 

Discussion  of  Phase  1  of  the  Methodology 

The  qualified  model  is  shown  in  figure  4-21.  For  the  most 
part,  the  qualified  model  is  a  literal  translation  of  the 
discipline  model.  The  only  part  of  the  model  that  was  changed 
was  in  the  area  of  groups,  classes  of  groups,  and  entities  that 
are  capable  of  being  grouped.  The  ease  of  translation  reflects 
the  stadsility  of  the  model,  ^is  model  was  modified  less  than 
any  other  discipline  model  in  the  initiation  effort.  As  a  result 
of  the  conversion  to  NIAM  and*  a  grouping  of  the  NIAM  diagram  to 
normal  form,  a  few  key  errors  were  detected. 

Some  of  the  application  areas  did  not  have  a  reading 
knowledge  of  NIAM  and  this  became  a  hardship  on  the  logical 
layer.  It  is  nearly  impossible  to  achieve  qualification  without 
at  least  one  member  of  the  application  team  (preferedsly  the 
liaison  person)  being  edDle  to  read  and  understand  the  NIAM 
diagrams.  It  was  felt  that  the  reading  knowledge  shown  by  the 
FEM  group  greatly  accelerated  the  validation  process. 

4.4.3  Review  of  Phase  2  of  the  Methodology:  Global 
Conceptualization  and  Integration 

The  global  model  is  shown  in  figure  4-22.  Only  the  area  of 
FEM  connectivity  and  FEM  coordinate  system  were  replaced  by 
generic  objects  in  converting  the  qualified  model  to  a  global 
model.  In  the  discipline  model  the  connectivity  of  nodes  is 
defined  at  the  element  level  by  an  ordered  list.  This  array  was 
replaced  by  the  vertex-edge  portion  of  the  topology  model.  The 
intention  was  to  use  a  single  consistent  method  of  modeling 
connectivity. 

It  was  decided  by  the  logical  layer  that  the  notion  of 
associating  multiple  coordinate  systems  with  a  "Place"  is  common 
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to  memy  applications.  In  the  global  model  of  FEM  there  are  no 
longer  any  references  to  coordinate  system.  It  is  suggested  that 
the  geometry  resource  model  be  changed  to  add  the  notion  of 
associating  multiple  coordinate  systems  with  a  place.  This  is  a 
good  example  of  how  resource  models  will  evolve  as  more 
applications  are  encountered. 
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T^irefrane  geometry  entities  were  accepted  as  generic 
entities  directly.  Therefore,  only  Phase  1  of  the  methodology, 
qualification,  exists  as  a  task  to  be  accomplished.  See  Appendix 
Cl  for  complete  model. 

We  intend  here  to  give  a  very  high  level  overview  of  the 
content  of  the  geometry  model.  Refer  to  figure  4-23  for  a 
taxonomy  of  the  objects  in  the  geometry  model.  Notice  that  the 
basic  breakdown  is  between  wirefreuae  geometric  entities  and 
wirefrzune  auxiliary  entities.  The  wireframe  geometric  segment  is 
fiirther  broken  down  into  Point  and  wireframe  geometric  Segment. 
The  main  atixiliary  cmtities  are  Curve,  Position,  and 
Transformation  Matrix.  2D  amd  3D  geometry  are  shown  as  mutually 
exclusive  subsets  of  geometry. 

Notice  also  the  key  relationship  between  wirefreme  geometric 
Segment  and  wirefreune  auxiliary  Curve  which  reads  ''wirefr2une 
geometric  segment  is  a  bounded,  connected,  oriented  portion  of  a 
wireframe  aiixiliary  curve."  Here  we  see  that  the  notions  of 
boundedness,  connectivity,  and  orientation  separate  pure  geometry 
from  auxiliary  geometry.  The  auxiliary  objects  serve  as 
unbounded  "building  blocks"  for  the  geometric  segments. 

Although  pareuaeterization  was  addressed  within  the  wireframe 
geometry  task  group,  it  was  not  modeled.  It  is  merely  indicated 
on  the  NIAM  diagram  that  all  auxiliary  curves  must  have  a 
parameterization.  It  has  been  questioned  by  some  members  of  the 
logical  layer  whether  parameterization  is  actually  a  conceptual 
notion.  Consideredale  time  and  effort  was  spent  attempting  to 
define  parauneterization  before  deleting  it  from  the  model  because 
we  could  not  model  it  adequately. 

The  appearance  of  "Place"  in  the  model  warrants  a  comment. 
Place  and  Point  both  specify  a  single  coordinate  location  in 
Euclidean  space.  The  difference  between  the  two  lies  in  their 
intended  use  in  the  model.  Point  is  used  as  model  geometry. 

Place  is  used  to  designate  location  when  what  is  being  located  in 
non-model  geometry,  such  as  the  center  of  a  circle. 

We  discovered  constraints  in  geometry  that  cannot  be  modeled 
by  the  MIML  subset  of  NIAM.  However,  by  using  more  advanced 
constraint  languages  within  NIAM  (not  contained  in  MIML)  we  were 
eddle  to  model  the  geometry  constraints.  There  are  also  problems 
that  occur  by  not  being  able  to  model  local  contexts  and  concepts 
such  as  instance  and  prototype,  first  class  objects,  and  copied 
objects.  From  these  exeunples,  we  see  the  feasibility  that  simple 
data  base  semantic  modeling  techniques,  by  themsleves  may  not  be 
adequate  for  the  PDES  modeling  effort. 
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*  We  noticed  while  doing  the  FEM  model  that  multiple 
coordinate  systems  were  used.  We  recommend  that  the  geometry 
model  be  updated  to  model  the  notion  that  a  given  place  may  be 
defined  In  multiple  coordinate  systems.  We  suspect  that  this  may 
be  a  requirement  for  many  applications. 

More  modeling  work  needs  to  be  done  on  the  spline  as  well. 
This  topic  was  also  addressed  by  the  wireframe  geometry  task 
group . 
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4.6  Example  6;  Presentation  Resource  Model 


Presentation  Is  the  act  of  making  product  models  visible  and 
is  not  inherently  part  of  product  definition.  However, 
presentation  data  is  often  transferred  between  dissimilar 
systems.  Because  presentation  is  not  part  of  product  definition, 
some  felt  it  should  not  be  part  of  our  initiation  modeling 
effort.  See  Appendix  C2  for  complete  model. 

We  have  chosen  a  compromise  position  by  going  ahead  and 
modeling  presentation  but  loosely  coupling  it  to  all  other  major 
classes  of  objects  such  as  geometry  and  text.  Presentation  is 
not  inherently  a  part  of  any  other  model  and  is  related  to  other 
models  only  through  associativities. 

After  considereible  study  on  modem  graphics  techniques  the 
logical  layer  came  to  the  conclusion  that  in  a  modem  graphics 
system  there  will  exist  two  structures:  1)  the  product  structure 
and  2)  the  presentation  structure  which  will,  to  a  great  extent, 
mirror  the  product  structure.  Keeping  these  structures  separate 
but  related  (presentation  structure  is  derived  from  product 
structure)  seems  to  be  the  key  to  modem  CAD/CAM  systems.  What 
one  sees  in  the  POES  presentation  model  then  is  the  NIAM  version 
of  the  presentation  structure  developed  by  the  presentation  task 
group.  Note  that  the  only  links  between  this  model  and  the 
geometry  and  text  models  are  the  associativity  objects  "curve 
element",  "sxirface  element"  and  "text  element".  See  figure  4-24. 

The  presentation  model  was  the  most  difficult  of  all  to 
build  and  consumed  a  month  and  a  half  of  effort.  The 
presentation  task  group  doctxmentation  was  voluminous  and  in 
places  difficult  to  understand  (mostly  because  of  the  logical 
layer  workers  lack  of  familiarity  with  modem  graphics 
standards) .  Of  the  month  and  a  half  effort  almost  a  month  was 
spent  in  solid  research  on  modem  presentation  standards  and 
techniques.  The  entire  PHI6S  document  was  read  as  well  as  most 
of  a  popular  college  text  book  on  graphics.  Putting  it  blxintly, 
this  model  was  a  real  "killer".  The  opinion  of  the  logical  layer 
worker  was  that  he  could  not  have  made  the  model  without  the 
research. 

The  model  went  through  approximately  five  iterations  before 
it  began  to  have  a  reasonable  correspondence  with  the 
presentation  task  force  model.  Part  of  the  difficulty  was  in 
interpreting  the  Pascal-like  models  in  the  presentation  task 
force  documentation.  In  many  cases  the  modeling  had  to  be  done 
directly  from  English  narrative. 

figure  4-24  is  an  overview  of  the  logical  layer  presentation 
model.  It  basically  shows  that  a  presentation  model  is  the  model 
of  a  picture  that  has  svib-picture  parts.  Each  picture  part  is 
composed  of  picture  part  elements  which  could  in  turn  be  another 
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picture  part  or  a  specific  association  between  a  definitional 
element  (geometry  or  text)  euid  some  number  of  visual  appearance 
attributes.  Note  that  it  is  not  mandatory  for  the  pictiire  part 
"assembly  structure"  to  mirror  the  product  definition  structure 
since  they  are  only  loosely  associated  at  the  elementary  geometry 
and  text  element  level. 

The  most  important  aspect  of  this  model  is  that  it  has  a 
structure  of  its  own  entirely  apart  from  any  definition  of  text 
or  geometry.  This  is  a  significant  departure  from  the  IGES 
world. 
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4.7  Example  7;  Topology  Resource  Model 


The  model  In  figure  4-25  is  the  temporary  model  referred  to 
earlier  in  this  report.  It  is  basically  the  pure  topology 
elements  lifted  from  the  I6ES  ESP  boxindary  representation  model. 
See  Appendix  C7  for  complete  model.  Again,  we  mention  that 
little  global  conceptualization  could  be  accomplished  without 
this  provisional  model.  It  is  envisioned  that  an  entire  class  of 
geometry-topology  associativities  will  eventually  emerge  as 
future  PDES  modeling  efforts  are  pursued.  It  was  our  desire  that 
this  model  stand  by  itself  with  no  references  to  geometry.  The 
following  sentences  are  taken  from  the  NIAM  model  and  highlight 
the  major  concepts: 

1.  A  vertex  is  either  the  start  of  and  edge,  end  of  em  edge  or 
a  degenerate  edge  for  a  loop. 

2.  A  vertex  may  participate  in  the  role  of  being  both  start 
and  end  of  the  edge. 

3.  If  a  vertex  is  playing  the  role  of  being  a  degenerate  edge 
for  a  loop  it  cannot  simultaneously  be  playing  the  role  of 
being  either  the  start  or  end  of  an  edge. 

4.  A  traversal  may  be  imposed  on  an  edge. 

5.  An  edge  must  have  a  start  vertex  and  an  end  vertex. 

6.  An  edge  is  distinguished  by  its  start  and  an  end  vertex. 

7.  A  loop  may  be  degenerate  or  it  may  consist  of  many  loop 
edges . 

8.  A  loop  is  a  boundary  for  a  connected  region  of  a  face. 
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Section  Five 


5.0  Lessons  Learned 

5.1  Use  Of  Several  Languages 


Most  of  the  lessons  learned  during  the  Initiation  work  stem 
from  the  fact  that  several  different  aodellng  languages  were 
used.  (Recall  that  both  the  application  area  models  and  the 
resource  models  were  allowed  to  take  virtually  any  form,  and  that 
IDEF-1  models  and  formal  language  models  were  encountered,  in 
addition  to  the  NIAM  and  the  DSL  models  that  were  generated 
within  the  Logical  Layer.) 

Because  so  many  lemguages  were  used,  there  has  been  some 
concern  2U30ut  not  having  some  agreed-upon  common  set  of 
conceptual  notions  that  we  could  use  as  a  principal  resource  in 
modeling.  We  realize  that  each  language  has  mechanisms  for 
triggering  these  conceptual  notions,  but  the  mechanisms  are 
different  for  each  language  and  lead  to  much  confusion  and  wasted 
effort  when  translating  between  languages. 

Our  study  of  data  base  semantics,  knowledge  representation, 
and  language  translation  leads  us  to  believe  that  the  formalism 
of  first  order  logic  with  some  extension  is  a  sufficiently 
neutral  mechanism  for  building  and  expressing  a  common  set  of 
conceptual  notions.  First  order  logic  has  a  simple  syntax  and 
agreed-upon  semantic.  With  the  extension  of  multiple  domains 
(formally  called  sorts),  the  notion  of  object  type  can  be 
expressed.  With  the  extension  of  lambda  functions  (and  a 
particular  Interpretation  of  them  that  allows  them  to  become 
predicates) ,  first  order  logic  can  conveniently  and  concisely 
express  arbitrary  complexity. 

Our  recommendation  is  that  any  language  that  is  to  be  used 
in  PDES  should  be  reconstructable  in  the  extended  first  order 
logic  language  iust  described  and  that  the  basic  conceptual 
notions  be  limited  to  those  of  first  order  logic.  Said  another 
way,  any  language  used  in  POES  should  be  an  interpretation  of 
first  order  logic. 

The  principal  conceptual  notions  of  first  order  logic  are: 
Individuals  are  quantifiable  (they  either  exist  or  they  don't) , 
true  or  false  relationships  can  exist  between  any  number  of 
individuals  (but  preferably  not  between  more  than  two  or  three  to 
keep  the  models  nearly  atomic) ,  and  arbitrarily  complex  functions 
can  be  formed  Involving  any  number  of  individuals.  These  should 
be  our  basic  conceptual  building  blocks.  Each  language  will  have 
its  own  particular  way  of  converting  these  notions  to  symbols. 

We  recommend  following  the  guidelines  estedalished  by  ISO  TC97  in 
evaluating  and  comparing  conceptual  schema  languages.  (See 
Reference  4 . ) 
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In  the  initiation  work,  we  underestimated  the  cost  of 
developing  high-quality  application  models  and  the  cost  of 
translating  between  languages.  We  were  never  able  to  attain  true 
translation.  Instead,  most  "translations'*  were  reinterpretations 
of  the  domain  of  discourse.  On  the  average,  five  translation 
iterations  were  required  to  achieve  acceptable  qualified  models. 

We  learned  that  information  models  evolve  like  any  other 
complex  artifact.  We  encountered  numerous  cognitive  styles 
within  the  application  areas,  each  reflecting  the  personal 
preference  of  the  modeler.  Some  preferred  text-based  models 
while  others  felt  more  comforteUsle  with  graphic-based  models. 

The  most  popular  graphic  form  was  IDEF-1  and  the  most  popular 
text  forms  were  variants  of  PASCAL  data  declaration  statements. 

We  had  particular  difficulty  modeling  the  content  of  the 
Presentation  docximent  because  it  appeared  to  represent  adsstract 
program  structures. 

5.2  global  Conceptualization 

The  most  significant  tasks  in  the  initiation  effort  were 
global  conceptualization  and  Global  model  building.  Recall  that 
global  conceptualization  is  the  act  of  discovering  how 
disciplines  are  similar  and  then  replacing  areas  of  similarity  in 
discipline  models  with  generic  entities  from  the  resoxirce  models. 
Global  models  then  relate  each  discipline  model  to  its 
corresponding  generic  entities  in  the  Logical  Layer  Model. 

Approximately  60%  of  the  project  time  was  spent  preparing 
qualified  resource  models  (geometry,  presentation,  topology)  and 
(qualified  discipline  models  in  preparation  for  global 
conceptualization  and  Global  model  building.  Only  about  20%  of 
project  time  was  spent  in  actual  global  conceptualization  and 
Global  model  building.  The  other  20%  of  the  time  was  spent  in 
creating  the  PDES  specification.  It  should  be  clear  from  these 
percentages  that  there  is  a  very  high  up-front  cost  in  getting  to 
the  global  conceptualization  and  Global  model  building  stage.  It 
also  suggests  that  we  need  to  concentrate  more  modeling  expertise 
at  the  .application  level  if  we  expect  the  Logical  Laver  to 
really  do  its  work.  It  would  seem  more  reasonable  that  the 
Logical  Layer  would  spend  20%  of  its  time  doing  resource  model 
development  and  model  qualification,  60%  on  Global 
conceptualization  and  Global  model  building  and  20%  on 
specification.  It  can  be  seen  from  our  actual  percentages  that 
we  did  not _ spend  the  majority  of  our  time  on  what  was  considered 
to  be  the  most  important  Logical  Laver  tasks.  We  do  recognize 
that  in  the  initiation  effort  that  considerable  time  was  required 
to  get  the  basic  resource  models  developed.  Any  follow  on  work 
that  expects  to  completely  rebuild  the  resource  models  should 
expect  a  high  up-front  cost  comparadjle  to  the  initiation  work. 
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No  signlflcamt  global  conceptualization  was  achieved  until  a 
provisional  topology  resource  area  model  was  built.  This  model 
was  borrowed  from  the  work  of  IGES  ESP  project  and  served  us 
well.  Once  we  built  the  topology  model  we  began  to  see  many 
different  kinds  of  expressions  of  connectivity  in  the  discipline 
models  that  could  be  factored  out  and  expressed  in  terms  of 
pieces  of  the  topology  model.  The  results  of  our  initiation 
effort  indicate  that  both  geometry  and  topology  entities  are 
fo\2ndational  to  almost  all  application  models. 

We  did  not  find  the  presentation  area  to  be  foundational  to  any 
application.  Presentation  appears  to  be  a  separate  structure 
which  can  be  constructed  by  traversing  the  actual  artifact 
structxire.  This  does  not  diminish  the  importance  of  exchanging 
presentation  information,  however.  Rather  than  including 
presentation  as  an  integral  part  of  any  model,  we  have  developed 
high-resolution  (in  the  spirit  of  PRIGS)  associativities  to 
geometry  and  text. 

Much  more  needs  to  be  learned  about  global 
conceptualization.  We  were  able  to  conceptualize  only  edsout  10 
to  20%  of  each  discipline  model  (meaning  that  we  were  able  to 
replace  10  to  20%  of  the  discipline  specific  entities  with 
generic  entities) .  We  should  face  the  possibility  that 
significant  global  conceptualization  may  not  be  achievable.  We 
should  also  think  in  terms  of  replacing  large  discipline 
specific  structiires  with  large  generic  structures  (as  in  the 
electrical  example)  instead  of  just*  replacing  single  objects. 
There  are  some  parallels  between  the  work  of  PDES  and  the  large 
body  of  knowledge  in  the  field  of  automatic  nattiral  language 
translation.  The  research  in  this  field  has  been  highly  inspired 
and  has  covered  many  years.  Should  we  expect  to  see  a  similar 
time  frame  for  global  conceptualization?  This  means  that  perhaps 
we  need  to  scale  down  our  expectations  for  the  near  term.  For 
example,  we  may  need  to  concentrate  on  just  getting  good 
conceptual  models  of  the  discipline  areas  and  not  attempt  global 
conceptualization  for  a  few  years  until  we  have  more  knowledge. 

5.3  People 

Turning  now  to  people  Issues,  the  most  important  role  of  the 
project  was  the  discipline  liaison.  In  developing  the 
methodology  we  envisioned  a  htiman  being  endowed  with  super  hximan 
qualities.  This  role  had  to  be  filled  by  a  person  recognized  as 
being  an  expert  in  his  application  area,  as  well  as  being  a 
modeling  expert.  We  did  not  find  these  kind  of  people,  and  the 
fulfillment  of  the  liaison  role  become  a  cooperative  effort 
between  a  discipline  expert  and  a  modeling  expert. 

The  liaison  role  is  a  critical  link  between  the  world  of 
application  knowledge  and  the  process  of  global  modeling.  We 
learned  quickly  that  acquiring  application  Icnowledge  and  modeling 
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It  is  very  time  consiimlng.  We  believe  there  are  similarities 
between  the  capture  of  PDES  application  knowledge  and  the  capture 
of  general  knowledge  in  the  field  of  knowledge  representation, 
where  the  automatic  tremslation  of  natural  language  into 
conceptual  models  is  an  intense  research  area.  Perhaps  we  need 
to  become  more  aware  of  work  being  done  in  general  knowledge 
representation . 


Modeling  is  new  to  most  people.  We  have  experienced  some 
delay  in  our  project  so  that  people  could  become  more  comfortable 
with  modeling  concepts.  People  are  still  making  the  shift  from 
thinking  in  terms  of  tables  (which,  incidentally,  is  not  their 
natural  mode  of  conceptualization)  to  thinking  in  terms  of 
objects  and  relationships.  Most  people  desire  to  abstract  away 
the  detail  in  structures,  and  the  modeling  aspect  of  the 
initiation  effort  has  forced  the  application  area  modelers  to 
reconsider  the  subtle  structures  embedded  in  their  application 
knowledge.  We  need  to  be  much  more  aware  of  the  work  done  in  the 
area  of  cognitive  psychology  when  trying  to  determine  a  style  of 
representing  application  knowledge.  PDES  represents  a  new 
approach  that  starts  with  humans  and  their  knowledge,  not  with 
computers . 

5.4  Cognitive  And  Specification  Models 

One  of  the  most  significant  things  we  discovered  in  our 
effort  was  the  distinction  between  the  cognitive  model  and  the 
specification  model.  (Recall  that,  roughly  speaking,  the 
cognitive  model  is  the  one  that  provides  the  environment  in  which 
to  think,  and  the  specification  model  is  the  one  in  which  the 
product  of  the  thinking  is  packaged. )  We  learned  the  following 
veTY, simple  lesson;  first  the  model  is  conceived  and  then  it  is 
packaged  -  don't  attempt  to  conceive  and  package  the  model  at  the 
same  time.  The  specification  model  itself  is  not  to  be  thought 
of  as  an  implementation  model,  and  should  not  be  any  less 
powerful  in  expressive  power  than  the  cognitive  model. 

In  terms  of  the  particular  techniques  used  in  the  initiation 
work,  the  NIAM  model  is  the  cognitive  model,  emd  the  DSL  model  is 
the  specification  model.  We  believe  that  this  decoupling  between 
thinking  and  specification  is  essential. 

5.5  Modeling 

We  have  learned  some  things  edsout  the  state  of  our  modeling 
art  within  the  Logical  Layer.  Some  of  these  things  are  expressed 
here  in  terms  of  the  NIAM  modeling  technique  that  was  used  to 
construct  the  global  models. 

One  of  our  observations  is  that  many  of  our  NIAM  conceptual 
models  contain  relationships  that  are  poorly  named.  We  probably 
have  too  many  ”has-of"  relationships.  This  is  an  indication  that 
we  are  modeling  the  structure  of  objects,  not  the  meaning  of 
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their  relationships.  This  may  have  something  to  do  with  the 
basic  roots  of  our  experience,  which  for  the  most  part  has  been 
progreun  development  and  dataJaase  design.  On  the  other  hand,  the 
field  of  knowledge  representation  seems  to  be  almost  obsessed 
with  identifying,  naming,  and  classifying  relationships.  Should 
we  follow  suit? 

Our  data  base  background  and  the  types  of  modeling  languages 
w_e__ajLe  _accustQmed  to .  t particularly  _IDEF~1  .and  NIAM)  have  caused 
u_8  JLa.  focus  our  thinking  about  relationships  _ into  two  general 
areas;  functional  dependency  and  cardinality.  These  two  basic 
notions _of  relationship  mav  not  be  sufficiently  powerful  to  model 
PDES  artifacts.  On  the  other  hand,  the  only  notions  of 
relationship  that  seem  to  have  universal  acceptance  are  those 
which  can  be  expressed  as  mathematical  relations.  The  notions  of 
causation  and  definition,  for  example,  do  not  have  agreed>upon 
meaning . 

There  was  some  concern  early  on  in  our  effort  that  the 
weakly  typed  NIAM  lainguage  would  not  be  adale  to  model  the 
complexity  of  the  artifacts  we  expected  to  be  modeling.  This  was 
not  the  case.  Strong  typing  makes  describing  complexity  more 
convenient  and  more  concisely  presentable  to  a  model  reader. 

Weak  typing  is  extremely  powerful  when  then  structure  of  an 
artifact  is  being  explored  amd  there  is  not  yet  a  desire  to  bind 
certain  objects  and  relationships  to  a  type  structure.  Weak 
typing  promotes  amorphous  model  structures  that  feed  the 
cognitive  process.  Strong  typing  leads  to  more  concise 
definition  and  named  abstractions  which  are  good  for  model 
packaging. 

5.6  Tr.anslation_Between  The  NIAM  Cognitive  Model  And  The,  DSL 

Recall  that  the  translation  between  the  NIAM  global  model 
and  the  DSL  specification  model  is  currently  a  manual 
process.  We  have  experienced  certain  difficulties  in 
the  initiation  work  in  carrying  out  this  process. 

In  the  DSL  language  it  is  obvious  that  the  language 
developer  saw  a  significant  distinction  between  a 
mandatory  relationship  and  an  essentially  defining 
relationship.  It  is  the  notion  of  essentially  defining 
relationship  that  gives  cohesion  to  most  DSL  entities. 

(An  exeuaple  of  a  mandatory  relationship  that  is  not 
essentially  defining  is  a  relationship  enforced,  say,  by 
company  policy  which  states  that  an  employed  must  be 
referred  to  formally  by  an  employee  number.  Certainly, 
the  relationship  between  a  person  and  his  employee 
number  is  not  essentially  defining.) 
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Now,  NIAM  uses  only  relationship  notions  that  can 
be  built  from  constructs  that  have  the  classical 
semantics  of  sets  emd  mathematical  relations  between 
sets.  So,  in  NIAM  any  other  subtle  notions  of 
relationship  are  hidden  in  the  interpretation  of  the 
name  of  the  relationship.  Therefore,  in  translating 
between  NIAH  and  DSL,  one  must  carefully  understand  the 
meaning  of  all  the  relationships. 

We  agreed  that  we  would  provisionally  augment  the 
NIAM  graphical  notation  by  adding  a  '*dot''  on  all 
relationships  that  we  felt  were  essentially  defining 
relationships.  Our  experience  so  far  has  been  that  this 
greatly  reduces  the  time  necessary  for  the  specifier  to 
understBmd  and  place  the  NIAM  model  into  DSL. 

We  were,  however,  extremely  reluctant  to  make  any 
changes  to  NIAM  syntax  as  its  power  is  in  the  leaness  of 
its  synteue.  We  have  reservations  about  ever  formally 
agreeing  on  a  definition  of  the  notion  ‘'defining 
relationship."  There  is  no  mathematical  formalism  that 
establishes  the  meaning  of  "defining  relationship." 

A  crucial  issue  in  building  the  specification  model 
from  the  global  cognitive  model  is  the  development  of  a 
rationale  for  grouping  the  global  cognitive  mode_l.  We 
recognize  grouping  as  2m  act  of  preparing  the  global 
cognitive  model  for  specification  we  do  not  recognize 
grouping  as  a  cognitive  act. 

5.7  Summary 


Our  experience  has  led  us  into  a  broader  knowledge 
of  conceptual  modeling.  Perhaps  the  most  important 
lesson  learned  is  that  we  had  to  remove  the  blinders  of 
our  own  experience  and  be  able  to  assimilate  the 
knowledge  of  other  people  on  the  project  and  people  in 
related  research  fields. 
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Section  six 


6.0  Critical  Issues  and  Reeoininendations 


This  section  will  deal  with  general  issues  and  specific 
issues.  General  Issues  relate  to  foundational  issues  of  the  PDES 
Logical  Layer  such  as  how  people  and  the  PDES  working  environment 
relate  to  languages,  conceptual  formalisms,  and  the  real  world  to 
be  modeled.  Specific  issues  derive  from  specific  problems 
encoxintered  during  the  application  of  the  methodology  and  their 
impact  on  the  direction  of  the  Version  1.0  Logical  Layer 
Activity.  This  section  concludes  with  recommendations. 


6.1  General  Issues 

Regardless  of  the  specific  direction  in  which  the  PDES 
Version  1.0  effort  heads  there  will  be  fundeunental  issues  tlriat 
must  be  dealt  with.  This  section  hopefully  will  prevent  us  from 
concentrating  too  hard  on  just  the  Initiation  Experience. 

6.1.1  People 


We  need  to  categorize  the  roles  of  people  into  three  broad 
areas:  1)  those  who  are  developers  of  methods,  tools,  and 
languages;  2)  those  who  support  the  application  of  methods, 
tools,  and  languages;  and,  3)  application  experts.  This  is  a 
rough  breakdown  for  the  purposes  of  exposition. 


With  regard  to  the  developers  of  the  methods,  tools,  and 
languages  for  PDES  Version  1.0,  we  should  seek  to  find  diversity 
in  experience  emd  attempt  not  to  focus  too  much  on  any  one 
particular  style  of  method,  model,  or  language.  PDES  itself  is 
c[uite  diverse  and  it  may  require  within  the  single  method  of  PDES 
a  diversity  of  approaches.  An  example  of  diversity  is  to  have 
developers  from  the  fields  of  information  engineering,  knowledge 
representation,  language  development,  natural  language 
translation,  and  cognitive  psychology. 


Methodology  support  persons  must  be  willing  to  adapt  to  a 
new  way  of  doing  things.  It  is  hard  to  think  that  the  PDES 
method  of  the  futxire  will  be  just  a  simple  adaptation  of  existing 
methods.  These  people  will  have  the  key  responsibility  to 
acclimate  others  to  the  method  and  in  this  sense  the  support 
people  are  quite  critical.  Obviously  these  people  should  already 
have  some  existing  background  in  the  fields  of  data  base, 
knowledge  representation,  or  modem  programming  languages.  We 
cannot  expect  application  experts  by  themselves  to  keep  a  new 
method  alive.  That  should  not  be  their  key  role. 


Application  experts  drive  the  method.  Nothing  in  the  method 
can  replace  their  expert  application  knowledge.  There  is  some 
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question  about  how  Involved  in  the  method  these  people  should  be. 
We  don't  want  to  dilute  their  energies  or  throw  artificial 
barriers  in  their  way  (they  may  possibly  perceive  that  any 
modeling  language  is  an  artificial  barrier) .  Actually  we  should 
not  speak  in  terms  of  a  single  expert  but  rather  a  group  of 
experts  who  cooperate.  This  gives  more  options.  If  the  group  is 
large  enough  it  may  be  possible  to  find  a  few  individuals  to 
become  more  involved  in  the  method  and  serve  as  representatives 
to  the  others.  The  principal  issue  of  the  knowledge 
representation  field  will  always  be  with  us:  how  do  we  get  the 
knowledge  from  the  expert?  There  seen  to  be  three  main 
approaches:  1)  have  a  knowledge  representation  expert  work  with 
the  application  expert;  2)  teach  knowledge  representation 
techniques  to  the  application  expert;  3)  develop  powerful  natural 
language  translation  software  that  can  automatically  build 
conceptual  models  during  a  machine-expert  dialogue. 

6.1.2  Environment 

The  environment  stages  the  development  of  the  PDES  standard. 
It  would  include  the  basic  methodology  which  frames  the  whole 
process  of  development,  giving  it  order  and  assigning  skill  and 
management  roles.  It  would  also  include  generalized  software 
that  will  allow  the  integration  of  specific  graphic  tools, 
modeling  languages,  and  translation  capabilities. 

Much  remains  to  be  done  in  terms  of  developing  the 
environment.  This  is  quite  a  critical  issue,  as  we  )cnow  that 
these  kinds  of  environments  (particularly  the  distributed  ones) 
are  just  now  coming  into  their  own.  Although  we  have  seen 
CAD/CAM  equipment  used  in  "spot  productivity"  modes,  we  are  still 
waiting  for  the  synergistic  environment.  The  "information 
engineering  environments",  long  overdue,  are  rapidly  becoming 
complex  products  running  on  small  desk  top  computers  or 
workstations.  At  least  these  products  should  give  us  a  vision  of 
a  modem  PDES  environment.  However,  we  must  characterize  the 
PDES  development  environment  and  resist  the  urge  to  adapt  an 
existing  one.  Admittedly,  this  is  an  idealistic  approach  but  it 
should  not  be  counted  out.  (The  section  on  specific  issues  will 
explore  other  alternatives  not  quite  so  idealistic.) 

6.1.3  Models  And  Languages 

Diversity  is  the  single  most  critical  issue  in  this  area. 
Diversity  stems  from  the  tremendous  breadth  of  PDES  application 
and  the  wide  variety  of  experiences  of  the  people  associated  with 
those  applications.  No  attempt  at  building  a  PDES  development 
environment  will  escape  the  impact  of  this  issue,  it  is  no 
harder  to  conceive  the  need  for  a  variety  of  representation 
techniques  than  it  is  to  conceive  the  need  for  a  variety  of 
people  to  run  a  company  or  a  toolbox  full  of  different  tools  to 
build  a  house. 


69 


We  fully  recognize  that  the  need  to  have  model  and  language 
diversity  seems  to  run  against  the  need  to  build  global  models  in 
a  single  language.  What  we  see  here  is  almost  the  equivalent  of 
the  problem  that  I6ES/PDES  Is  attempting  to  solve  in  the 
evolution  of  a  product.  Each  life  cycle  stage  seems  to  have  its 
own  representational  needs  but  each  desires  a  common  way  of 
communicating  that  representation  in  an  application  free  mode. 

The  need  for  diversity  of  language  and  representation  leads 
naturally  to  the  development  of  a  common  representational 
foundation  that  is  "neutral"  to  all  application  representations 
and  languages.  PDES  must  not  get  into  a  war  of  languages  over 
the  need  for  diversity.  Without  a  common  foundation,  pairwise 
comparisons  of  languages  will  dilute  our  efforts. 


We  have  done  considerable  research  during  the  initiation 
effort  to  discover  the  "right"  foundation  form_alism.  We  believe 
the  language  and  notions  of  formal  logic  are  sufficiently 
powerful  to  serve  as  this  foundation.  This  is  not  just  our 
opinion.  It  is  also  shared  by  others  in  fields  where  diversity 
<uid  desire  for  \inification  are  also  occuring  such  as  data  base, 
knowledge  representation,  euid  linguistics.  We  would  hope  that 
such  pragmatic  issues  as  weak  typing  versus  strong  typing,  text 
versus  graphics,  atomic  versus  non-atomic,  procedural  versus 
declarative,  and  representation  styles  such  as  rules,  nets, 
frames,  and  objects  do  not  erode  o\ir  desire  to  create  this 
essential  foundation.  This  foundation  is  the  "IGES  within  I6ES". 

6.1.4  Broad  Knowledge 


This  issue  is  really  just  a  statement  of  a  common  theme 
running  through  the  discussion  of  the  other  issues,  but  is 
significant  enough  to  demand  special  attention.  We  must  be 
careful  in  developing  the  PDES  that  our  knowledge  becomes  too 
narrow  and  focused.  For  instance,  we  could  use  traditional  data 
base  development  methodology  as  a  start  point  for  developing  and 
executing  an  initial  PDES  method,  or  we  could  use  our  knowledge 
of  strongly  typed  programming  languages,  or  try  the  latest  tricks 
in  logic  programming. 


The  PDES  initiation  effort  was  probably  too  focused  on  data 
base  semantics  (more  edaout  this  later) ,  but  because  of  the  time 
frame  it  was  justifiedsle  to  take  an  approach  and  znin.  The 
Version  1.0  effort  should  assimilate  as  much  knowledge  as  it  can 
in  the  time  frame  allowable.  It  is  worth  consideration  that 
building  a  broad  knowledge  base  and  perspective  should  actually 
drive  the  schedule. 


6.2  Specific  Issues 
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6.2.1  Pecpplg 

Although  there  was  a  large  fanily  of  participants  in  the 
Initiation  effort,  the  group  that  ultimately  developed  the  method 
and  initial  content  of  the  logical  layer  was  rather  small. 

Members  of  the  group  were  separated  by  hundreds  of  miles  and  had 
very  limited  personal  contact  with  each  other.  This  is  probably 
normal  for  standards  efforts.  But  PDES  is  a  different  kind  of 
stemdards  effort  that  may  demand  a  shift  from  the  norm.  The 
amount  of  time  for  which  companies  will  volunteer  their  people 
will  have  a  direct  impact  on  the  quality  of  PDES  results. 

From  our  experience,  the  size  of  the  application  groups  was 
adequate  in  most  cases,  but  there  were  some  groups  of  just  a  few 
people.  A  size  of  fifteen  or  so  seems  appropriate.  It  is 
questionable  how  big  the  logical  layer  group  can  be  and  still 
function  without  inter f erring  each  other.  Obviously  there  are 
some  ground  for  specialization.  The  Phase  1  methodology  efforts 
in  qualification  can  be  independent  efforts  with,  say,  one 
modeler  dedicated  to  each  application  area.  Phase  2  must  be  a 
cohesive  group  of  probably  not  more  than  7  people  dedicated  to 
pushing  the  leading  edge  of  conceptualization.  We  recognize  the 
need  for  "spot”  consulting  support  from  academic  and  industrial 
experts  in  the  field.  We  emphasize  "academic”  support  which  was 
almost  totally  missing  from  the  initiation  effort. 

We  have  already  written  about  our  experience  in  allowing 
unlimited  selection  and  usage  of  languages  on  the  part  of  the 
application  area.  Perhaps  we  need  to  limit  this  language  set  to  ' 
a  qualified  five  or  six.  Perhaps  if  more  individuals  were 
assigned  to  qualify  application  models,  each  qualifier  could  be 
teamed  up  with  an  application  area  using  a  modeling  language  thett 
the  qualifier  is  already  familiar  with.  In  other  words,  try  to 
limit  the  C[ualifier  to  just  two  languages:  the  standard  model 
language  of  the  logical  layer  and  a  single  application  language. 

Participants  in  the  PDES  effort  must  believe  that  the 
methodology  will  work  and  play  their  assigned  role(s).  Job 
specialization  may  be  the  "revolution”  within  the  information 
revolution.  We  obviously  need  to  learn  from  very-large  proje' -s 
and  how  work  is  divided.  '  The  initiation  effort  gives  a  good 
start  in  classifying  the  kinds  of  roles  to  be  played. 

People  must  agree  on  certain  styles  of  modeling  the 
qualified  schema  as  this  will  ease  the  burden  of  the  Phase  2 
conceptual izers.  This  brings  up  a  serious  issue:  finding  enough 
people  who  model  well  in  any  modeling  language  who  are  willing  t 
adopt  a  common  style.  Because  we  had  basically  only  one  model 
qualifier  in  the  initiation  effort,  we  were  not  able  to  gain 
experience  in  this  area. 
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A  significant  issue  regarding  people  is  the  complexity  of 
language  with  which  application  persons  will  be  willing  to  work. 
If  the  language  is  weak  then  we  lose  valuable  application 
knowledge  because  the  language  cannot  express  it.  If  the 
language  is  too  rich  we  lose  valuedsle  application  knowledge 
because  experts  won't  learn  it.  We  have  applied  the  "walk  before 
run"  principle  in  the  initiation  effort  and  have  settled  on 
fairly  simple  classes  of  languages  that  are  easy  to  learn  and 
use.  We  want  to  "walk"  now,  but  we  perceive  that  we  may  have  to 
"run"  later.  We  are  not  convinced  that  languages  richer  than  the 
ones  we  are  already  using  will  pay  off  in  the  near  term. 

6.2.2  Environment 

The  environment  for  the  initial  effort  was  minimal.  It  was 
basically  composed  of  a  description  of  a  methodology,  an 
allocation  of  languages  to  phases  of  this  methodology,  and  a  few 
informal  agreements  with  the  application  layer.  Early  on,  there 
existed  no  doc\imentation  standards,  such  as  the  kits  in  the  IDEF 
methodology.  Later  in  the  effort,  a  standard  kit  for  application 
model  documentation  was  suggested. 

Although  the  methodology  was  simple,  it  did  serve  to  give  us 
guidance.  The  basic  three  phase  methodology  should  be  adequate 
for  the  PDES  Version  1  Logical  Layer  work;  however,  other  aspects 
of  the  environment  must  be  further  developed.  A  model 
configuration  management  subsystem  should  be  developed.  Computer 
assisted  graphics  for  building  models  is  badly  needed  to  replace 
the  pen-and'ixik  approach  of  the  initiation  effort.  A 
computerized  conceptual  dictionary  with  a  powerful  query 
capability  will  be  needed  in  the  PDES  version  1  effort. 

We  envision  an  environment  consisting  of  a  network  of 
workstations  (or  at  least  personal  computers)  with  a  central 
model  administrator.  Most  likely  the  global  PDES  model  will 
become  large >enough  that  it  must  be  stored  on  a  mainframe.  We 
are  just  now  seeing  examples  of  information  engineering 
workstation  environments  appearing  in  the  marketplace.  This  is 
encouraging,  and  we  suggest  that  these  new  products  be 
investigated.  Graphics  support  for  information  modeling  is  also 
becoming  availzdale.  A  critical  aspect  of  the  PDES  Version  1.0 
work  should  be  to  investigate  these  emerging  caped^ilities. 

A  critical  issue  that  affects  the  development  of  the 
environment  is  a  thorough  characterization  of  PDES  information. 

Is  it  mostly  numeric  or  is  there  a  significant  symbolic 
component?  What  is  the  mix  of  administrative,  engineering,  and 
shape-related  information?  Bascially  there  is  no  "strategic" 
picture  of  PDES  information. 
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The  methodology  used  in  the  initiation  effort  did  not  have  a 
strong  project  management  component.  It  only  suggested  the 
technical  content  with  plausible  deliveredsles  between  phases. 

The  methodology  does  not  suggest  a  way  in  which  it  may  be 
operationally  placed  within  the  I6ES/P0ES  organizational 
structure.  The  initiation  effort  did  not  attempt  to  determine 
what  kind  of  impact  a  methodology  would  have  on  existing 
I6ES/PDES  operating  principles  and  protocol. 

6.2.3  Models  And  Languages 

A  critical  issue  is  whether  to  allow  an  unlimited  number  of 
application  modeling  techniques.  The  PDES  Version  1  effort  needs 
to  consider  at  least  three  alternatives:  1)  unlimited  modeling 
techniques  2)  a  single  standard  technique  or  3)  a  limited  set  of 
techniques.  The  cost  of  living  with  several  languages  is  quite 
high.  Because  most  people  are  not  yet  culturally  locked  into  any 
given  modeling  technique  (although  entity-relationship  techniques 
seem  most  popular) ,  we  should  take  advantage  of  the  flexibility 
that  we  still  have  to  find  the  best  lauaguage(s) . 

We  strongly  recommend  using  graphics-supported  modeling 
tegbnicrues  at  the  application  layer  and  in  phase  1  and  phase  2  of 
the_loqical  layer  methodology  (the  cognitive  portion) .  We  are 
aware  of  the  limitation  of  graphical  techniques  in  voicing 
constraints  and  suggest  that  mixed  graphic/text  techniques  be 
chosen.  Ho.  modeling  technique  should  be  chosen  that  does  not 
hevfi  a  single  uniform  text  language. in  which  anv  construct  of  the 
model inq  technique  (whether  graphic,  or. _text)  mav  be  expressed  in 
a,_CQmPUter  sensible  form. 

It  is  strongly  suggested  that  a  single  (i.e.,  the  same) 
modeling  technique  be  used  for  phase  1  emd  phase  2  of  of  the 
methodology.  This  technic[ue  should  be  a  detail-exposing  one.  It 
should  allow  completely  \ingrouped  modeling  to  occur. 

Particularly,  it  should  not  force  the  phase  1  euid  2  modelers  to 
use  the  relational  model,  or  the  entity  attribute  relationship 
model,  as  popular  as  these  models  are.  It  should  exploit  natural 
language  expression  of  relationships  and  constraints  as  much  as 
possible. 

The  Version  1.0  effort  should  be  concerned  about  the 
expressive  power  of  the  application  modeling  language (s).  A 
language  that  is  expressively  weedc  may  only  push  the  application 
modeling  work  down  into  the  qualification  phase  of  the  logical 
layer.  A  language  that  is  too  strong  may  be  perceived  as  an 
artificial  barrier  to  the  application  expert.  A  compromise  is  to 
choose  a  reasonably  strong  language  with  graphical  support  and 
let  the  expert  express  in  English  what  he  cannot  express 
formally.  The  mappings  between  a  constraint  in  English  and  the 
seune  constraint  in  a  formal  constraint  language  are  almost  never 
straight  forward  even  for  the  simplest  of  constraints.  We 
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definitely  see  the  phase  1  and  phase  2  workers  as  being  experts 
in  FOBHAL  constraint  articulation.  If  the  worker  is  not  capable 
of  converting  natural  language  constraints  into  well*formed 
sentences  in  predicate  logic/  he  is  probedsly  not  expert  enough. 

We  even  suggest  the  possibility  that  first  order  logic  be  a 
staging  area  for  expressing  constraints  even  before  they  are 
voiced  in  a  specific  modeling  language. 

This  leads  us  to  another  issue:  the  need  for  a  common 
conceptual  formalism.  PDFS  cannot  become  a  circus  of  languages 
with  each  language  having  its  own  set  of  proponents.  The 
formalism  serves  as  common  ground  for  the  understanding  of  two 
modeling  languages  and  also  can  be  a  stemdard  neutral  form  in  the 
translation  between  two  dissimilar  languages.  The  ISO  TC97 
guidelines  for  conceptual  schema  languages  is  an  exeunple  of  the 
use  of  logic  as  a  reference  for  evaluating  languages.  We 
strongly  recommend  that  formal  logic  be  used  as  the  common 
conceptual  formalism.  As  suggested  earlier,  we  suggest 
spgci.ficallv_the  use  of  the,  first-order  predicate,  logic  language 
as  the  standard  neutral  language  to  be  used  in  all  cases  of 
arbitration  of  meaning  _and  comparison  of  modeling  languages.  We 
further  suggest  that. before  anv  language  is  used  that  it  be  shown 
how_that.langua_gc_can  be  reconstructed,  in  first-order  predicate 
logic.  We  realize  the  limitations  of  first~order  logic  and  see 
the  critical  need  to  extend  it  to  be  able  to  express  arbitrarily 
complex  abstractions  ranging  from  simple  types  to  complex 
generalization  and  aggregation  abstractions.  We  have  observed  a 
similarity  between  the  complex  utterances  of  natural  language  and 
the  complex  artifacts  of  PDFS  and  suggest  that  we  investigate 
some  of  the  same  techniques  being  used  to  convert  natural 
language  to  conceptual  models.  Laxobda  abstracting  is  such  a 
technique . 

The  initiation  effort  basically  borrowed  data  base  modeling 
techniques  to  do  most  of  its  work.  This  approach  has  only 
partially  captured  application  semantics  and  should  not  be 
perceived  as  the  ultimate  modeling  solution.  The  PDFS  Version 
1.0  effort  should  be  on  a  path  to  capture  full  application 
semantics.  This  suggests  a  broadening  of  our  modeling  approaches 
to  include  those  being  used  by  the  field  of  knowledge 
representation.  Choosing  languages  which  are  expressively  weak 
will  result  in  incomplete  formal  models  of  applications  areas 
(natural  language  patches  will  most  likely  get  lost  in  the 
process).  It  is  critical  that  PDFS  Version  1.0  look  beyond  data 
base  languages. 

HeitheiL  IDEFrL.nQr  the  MIML_s_ubset  of  KIAM_ls  considered 
BOwerfu]^ enough _f or  the  Version  l.O  effort.  Neither  has  the 
express ive_power..of_the  first-order  logic.  IDEF«l  is  extremely 
weak__in  declaring  constraints  J  The  MIML  subset  of  niam  is 
somewhat  stronger.  A  language  exists  to  extend  the  constraint 
power  of  the  MIML  subset  of  NIAM,  but  our  understanding  is  that 
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subset  of  NIAM  can  be  extended,  we  suggest  looking  for  a  new 
language.  The  developers  of  DSL  are  presently  working  on 
extensions  to  extend  its  expressive  power.  We  suggest,  however, 
that  DSL  be  used  exclusively  as  a  specification  language  in  the 
Version  1.0  effort.  It  must  have  the  expressive  power  of  the 
Phasel/2  language. 

6.2.4  Broad  Knowledge 

The  issue  here  is  that  those  involved  in  the  Version  1.0 
effort  must  have  a  broader  knowledge  of  modeling  techniques  and 
lemguages  than  did  those  in  the  initiation  effort.  Because  of 
schedule  constraints,  the  initiation  effort  concentrated  on  using 
the  modeling  knowledge  its  members  already  had  in  order  to 
quickly  test  a  methodology  and  build  content.  The  Version  1.0 
effort  should  not  follow  the  same  course.  If  maintaining 
schedule  within  PDES  is  the  driving  motivation,  we  can  expect  to 
see  a  narrow  focus  on  modeling  technology  and  a  resultemt  loss  of 
capture  of  application  meaning.  The  capture  of  application 
meaning  must  be  at  the  heart  of  any  PDES  effort  that  seeks  to 
follow  the  development  guidelines  of  the  second  PDES  Report. 

A  specific  exzunple  of  adopting  a  broad-knowledge  attitude  is 
the  acceptance  of  logic  as  formal  foundation  for  modeling.  We 
have  already  seen  this  broadening  aspect  in  the  field  of  data 
base,  knowledge  representation,  and  natural  language  translation. 
The  trend  seems  to  be  that  workers  in  these  fields  are 
understanding  the  importance  of  formalisms.  We  believe  that  PDES 
should  follow  suit. 

A  specific  area  where  we  are  lacking  formal  thinking  is  in 
the  development  of  the  global  models.  We  are  presently  using 
informal  terminology  such  as  "resource  model"  and  "user  model." 

In  the  language  of  logic  and  axiomatic  systems,  concepts  that  are 
defined  as  true  (the  elementary  building  blocks}  are  called 
axioms.  Deduction  is  then  used  as  a  powerful  tool  to  build  new 
concepts.  A  broadened  knowledge  of  conceptual  modeling  should 
accept  the  principles  of  logical  deduction  as  a  necessary  tool. 
Deduction  adds  a  generative  flavor  that  is  missing  from  our 
present  repertoire  of  basic  concepts. 
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Section  Seven 


7.0  Summary  Of  Lessons  Learned  And  Recommendations 

This  summary  section  proceeds  from  two  fundeo&ental  points: 

1)  It  Is  the  Information  In  the  application  models  that  Is 
to  be  exchanged. 

2)  the  needs  of  PDES  dictate  that  these  models  are  to  be 
computer-sensible,  and  able  to  be  exchanged  with  their 
structiire  Intact. 


Lesson  Learned: 

There  Is  a  shortage  of  good  modelers. 

Recommendation: 

Encourage,  sponsor,  publicize,  etc.  programs  that  promote 
modeling. 


Lesson  Learned: 

Lack  of  modeling  expertise  can  delay  schedules. 
Recommendation: 

Insist  on  (Quality  models  over  fast  schedules. 


Lg8?,gn 

The  Logical  Layer  work  of  conceptualization  and  Integration 
proceeds  first  by  perception,  concept  discovery,  and  exposition 
of  detail,  and  ^en  by  specification.  The  decoupling  Is 
essential . 

Recommendation: 

These  two  types  of  activity  should  be  supported  by  cognitive 
and  specification  models,  respectively.  The  cognitive  modeling 
technique  should  have  a  graphics  component.  The  two  models 
should  have  equivalent  descriptive  power,  and  both  should  have  a 
computer  sensible  representation.  The  two  models  should  share  a 
common  foundation  based  In  first  order  predicate  logic. 

Neither  IDEF-1  nor  the  MIML  sxibset  of  NIAM  Is  considered 
powerful  enough  for  the  Version  1.0  effort.  If  neither  can  be 
extended  to  have  the  expressive  power  of  first  order  logic,  a  new 
language  should  be  sought. 
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Global  conceptualization  and  integration  is  a  human 
intensive  activity  that  cannot  be  accomplished  in  large  groups. 


Recommendation: 

Local  conceptualization  must  occur  systematically  at  the 
Application  Layer  before  expecting  the  Logical  Layer  to  do  global 
conceptualization  and  integration 


Lesson  Learned: 

The  cost  of  living  with  several  languages  at  the  Application 
Layer  is  quite  high. 

Recommendation : 

Either  mandate  a  single  technique  or  limit  the  set  of 
techniques.  If  more  than  one  technique  is  allowed,  the 
techniques  allowed  must  share  a  common  conceptual  formalism.  The 
appropriate  formalism  is  first  order  predicate  logic. 


Lesson  Learned; 

The  discipline  liasion  role  is  the  most  important  role  of 
the  project. 

Recommendation; 

Find  the  application  experts  who  have  an  interest  in 
modeling,  and  cultivate  that  interest. 


Lesson  Learned: 

Don't  automatically  assume  that  traditional  data  base 
technic[ues  will  suffice  when  dealing  with  our  data  exchange 
problem.  We  couldn't  model  everything  we  wanted  to  in  a  useful 
computer  form  because  the  modeling  techniques  we  had  were  geared 
to  administrative  type  structures,  not  more  complicated  FDES  type 
artifact  structures. 

Recommendation; 

Don't  attempt  Version  1.0  in  this  state  of  affairs,  because 
the  needs  of  PDES  call  for  computeUsle  models. 


Lesson  Learned; 

There  is  a  difference  between  following  a  development 
process  for  writing  a  data  exchange  specification,  and  actually 
using  that  specification  to  exchange  data  in  the  manner  intended. 
Data  exchange  involves  user  data  bases  and  vendor  translators. 
Many  data  exchange  issues  have  not  yet  even  been  raised,  much 
less  resolved.  The  PDES  effort  in  some  ways  is  a  multi-company 
research  effort  based  on  volxinteer  labor. 

Recommendation t 

Begin  immediately  to  learn  what  data  exchange  in  a  PDES 
environment  might  involve.  For  example,  what  the  structure  of 
user  data  bases  must  be,  what  translator  capzdailities  will  be 
required.  Achieve  an  understanding  that  the  factor  of  the 
unknown  may  affect  schedules  in  ways  \insuspected  as  yet. 


Lesson  Learned: 

We  were  significantly  affected  by  the  lack  of  computerized 
tools  particxilarly  graphics  support  for  creating  modeling 
diagrzuns.  We  had  no  full-feature  conceptual  dictionary. 

Recommendation; 

Develope  a  specification  for  an  information  modeling 
development  envrionment  and  procure  the  environment  before 
serious  effort  at  PDES  V  1.0  is  started. 


Lesson  Learned; 

We  believe  that  the  methodology  developed  in  the  initiation 
experience  is  a  proper  framework  for  development  of  PDES  content. 
Although  some  phases  and  techniques  must  mature,  we  believe  there 
are  no  major  missing  pieces  in  the  methodology. 

Recommendation; 

Use  the  methodology  as  developed  in  the  initiation  effort  as 
the  freunework  for  developing  PDES  V  l.o  content. 
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This  appendix  consists  of  statements  by  task  leaders  or  other 
persons  involved  in  the  developement  of  the  various  models  used 
in  the  initiation  effort.  The  statements  sxunmarize  their 
reaction  to  the  use  of  modeling  techniques  in  carrying  out  the 
work  for  the  initiation  effort.  The  contributors  to  this  section 
are  also  the  contributors  to  Section  3. 


-  Ed 


Let  me  start  by  saying  that  this  is  an  interim  emd  purely 
personal  assessment  of  the  utility  of  NIAM  modeling  techniques  in 
the  building  of  PDES/STEP.  I  have  not  yet  discussed  my 
reservations  with  either  John  Zimmerman  or  Paul  Thompson.  I  have 
very  high  regard  for  both  of  them  and  their  efforts  and  feel  that 
it  would  be  useful  to  work  out  my  thoughts  with  at  least  one  of 
them. 

This  is  a  portion  of  an  effort  on  my  part  to  try  to 
critique  the  PDES  efforts  to  date.  A  number  of  people  have  done 
a  lot  of  inadequately  appreciated  work  which  deserves  both 
carefxil  review  and  analysis.  This  paper  is  neither,  being  merely 
an  attempt  to  indicate  some  concerns  I  have  about  the  use  cf  NIAM 
in  PDES. 

There  are  some  positive  things  I  can  say  about  NIAM.  Two  of 
the  purposes  of  a  formalism  are  to  help  organize  and  clarify. 

NIAM  does  this  in  working  with  POES  constructs.  The  visual 
approach  may  well  make  it  easier  to  get  an  idea  for  what  is  going 
on,  much  as  state  diagreu&s  are  easier  to  vinderstand  than 
equivalent  descriptions  of  finite  state  machines.  This  is 
helpful  both  for  the  people  working  on  a  particular  application 
and  for  the  people  wishing  to  ensure  that  the  constructs  of  one 
application  are  not  merely  pieces  of  some  other  application 
indisguise. 

Now  for  the  "howevers". 

Two  of  the  major  criticism  of  IGES  made  by  the  user 
community  were  the  size  of  IGES  files  and  the  length  of 
processing  time.  While  it  might  be  reasonable  to  decide  that 
PDES  be  inherently  less  efficient  in  these  ways,  that  decision 
and  the  reasons  for  it  should  be  made  explicitly.  NIAM  was 
designed  to  decompose  data.  This  has  led  to  u  proliferation  of 
entities  which  would  be  expected  to  lead  to  increased  file  sizes 
and  processing  times. 

Just  as  state  diagrams  are  not  used  in  proving  theories 
about  finite  state  machines,  it  seems  to  me  that  the  correct 
place  to  be  formal  about  what  is  being  said  is  in  the  DSL  and 
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that  the  people  working  at  the  application  level  are  the  ones  who 
need  to  make  the  formal  statements  about  the  data. 

The  separation  of  file  syntax  from  the  application  by  two 
(NIAM  and  DSL)  levels  makes  it  much  harder  to  introduce 
processing  efficiencies. 

Lastly,  the  extra  process  between  the  application  and  the 
physical  layers  makes  it  much  more  difficult  to  incorporate 
changes.  In  the  initial  stages  of  building  PDES  it  would  be 
useful  to  be  able  to  quickly  build  and  test  prototypes. 
Applications  writing  to  the  DSL  would  be  eUble  to  do  so  far  more 
efficiently  than  those  writing  to  NIAM. 

Electrical  Schematic  Modeling  Experiences  »  Curt  Parks 

Prior  to  the  PDES  initiation  effort,  model  development 
within  the  Electrical  Applications  Subcommittee  had  progressed  to 
the  point  where  the  benefit  of  information  modeling  for 
application  data  requirements  and  for  data  relationship  proofing, 
given  a  target  application  environment,  coulii  be  verified.  The 
environment  was  the  I6ES  physical  format,  and  the  data  content 
was  that  of  several  known  CAD  systems  used  for  the  design  of 
Printed  Wiring  Assemblies.  (See  Section  3.3.3)  The  model  also 
served  as  a  guide  when  test  cases  were  developed  following  the 
definition  of  IGES  extensions.  The  results  of  this  experience 
with  modeling  are  extremely  significant.  The  Electrical 
Applications  Committee  will  no  longer  propose  data  entities  for 
inclusion  in  a  specification  without  first  constructing  and 
validating  a  logical  model. 

The  schematic  model  for  PDES  had  several  additional  aspects: 

1.  The  model  was  to  be  independent  of  any  application 
environment  or  physical  data  format. 

2.  The  more  expressive  modeling  provided  by  IDEF-1 
Extended  would  be  used. 

3.  Computer  modeling  aids  were  used  or  evaluated. 

4.  The  resulting  model  would  be  subject  to  integration 
with  other  application  models. 

The  initial  model  required  only  a  few  hours  work  by  two 
people  who  were  feuniliar  with  the  application  and  the  new  IDEF-1 
Extended  rules.  Either  a  related  application  model  (as  in  this 
case)  or  a  collection  of  entities  extracted  from  reference 
reports  serve  well  as  input.  Working  with  "collections"  of 
dependent  and  independent  entities  ranging  from  5  to  about  15  on 
each  page  was  quite  effective.  The  model  walk-throughs  were  made 
much  easier  by  the  groupings,  and  no  need  was  found  to  further 
reduce  the  entities-per-page  after  consensus  was  reached. 
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The  development  from  the  initial  model  consiimed  the  bulk  of 
time,  and  was  mostly  due  to  human  factors,  ^iven  5  to  6  meeting^ 
sessions  per  year  and  a  changing  membership.  Each  meeting 
session  required  a  review  of  the  modeling  language,  and  the 
criteria  for  entities  in  the  model.  A  frame  of  reference  was 
required  wherein  the  members  had  to  conceptualize  the  information 
found  in  the  application  as  opposed  to  the  more  vocationally 
revelant  view  of  its  usage.  Following  an  overview  of  the 
previous  model,  and  the  changes  made  to  it,  problem  areas  could 
be  identified  and  discussed.  After  each  meeting  all  agreed-upon 
changes  or  additions  were  incorporated,  and,  following  the  IDEF 
"kit"  procedures,  the  new  package  was  sent  to  attendees. 

The  model  kits  were  also  made  availzOsle  for  comment  to 
people  and  organizations  not  attending  the  work  sessions.  No 
comments  were  received  from  such  sources,  except  the  model 
integration  team.  The  EAC  is  presently  exploring  ways  of 
bringing  a  wider  range  of  experts  to  the  model  reviews,  or 
holding  the  reviews  at  gatherings  of  users  and  experts. 
Eventually,  for  the  assurance  of  the  acceptance  of  PDES  by 
vendors  and  users,  they  must  (to  whatever  degree  possible)  be 
brought  into  reviews  for  both  application  and  logical  layer 
consensus. 

At  present,  the  modeling  methodology  is  seen  by  the  EAC  as 
the  best  means  of  developing  a  logical  schema,  but  more  people 
must  understand  what  logical  models  are  and  how  they  are 
developed.  The  use  of  the  picture-like  language  has  greatly 
increased  meaning  to  people  during  reviews.  Further,  those 
pictures  must  be  drawn  by  people  to  insure  human  "readability". 
The  computer-automation  was  effective  only  as  a  normalization  and 
verification  tool  after  the  model  was  created.  Interactive 
graphics  computers  work  well  for  producing  "polished"  model 
views,  but  models  produced  by  automation  from  model  data  were  not 
Buit2d3le  for  reviews  or  kits.  The  layout  produced  by  the 
automated  software  seems  too  spread  out  for  convenient  viewing. 

During  the  intergration  phase,  the  use  of  a  different 
modeling  methodology  had  both  good  and  bad  aspects.  The 
conversion  forced  a  complete  "what  was  meant"  review  of  the 
application  model  views  and  glossary.  Areas  were  thereby 
discovered  where  entity/ attribute  names  could  be  adjusted  to 
align  with  other  models.  The  conversion  was,  however,  an  extra 
step  which  tended  to  remove  the  results  away  from  further  review 
by  the  application  committee.  The  original  model  language  seems 
to  convey  something  akin  to  poetic  essence  which  is  often  lost 
when  translated,  even  though  the  content  is  retained.  When  the 
model  is  further  reduced  (e.g.,  to  Metamodeler  output  or  a  DSL) 
to  text,  a  group  review  becomes  all  but  impossible. 
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Reduction  of  a  model  to  English  sentences  seemed  to  help 
only  when  done  verbally  as  part  of  a  model  valk>through.  Again, 
pictures  can  retain  interest  where  sentential  facts  are  dry  to 
the  point  of  disinterest. 


The  process  of<  integration  would  have  been  greatly  aided  if 
a  logical  layer  product  model  had  been  developed  first.  Each 
model  needed  a  focus  in  the  form  of  a  PART,  COMPONENT  PART,  PART 
VERSION  entity  structure.  This  is  now  being  developed  for  PDES 
and  will  greatly  help  future  application  modeling.  In  turn,  the 
product  model  should  be  constrained  by  a  definition  of  domain. 

The  domain  question  is  vital  to  the  entire  PDES  effort.  Is  a 
product  in  PDES  format  going  to  be  edsle  to  produce,  or  to 
replace,  a  drawing  or  blueprint?  Is  it  to  include  the  entire 
product  life-cycle  (another  dimension  of  product  definition)?  Or 
must  it  convey  the  as-designed  product  against  which  an  as- 
manufactured  and  as-maintained  product  can  be  compared?  The 
follow-on  electrical  product  model  is  being  developed  in  a  narrow 
domain  (no  blueprint,  as-designed)  to  avoid  the  multi-dimensional 
aspect  possible  and  the  related  confusion.  The  resultant  model 
can  be  expanded  later  given  a  consensus  on  the  larger  domain  PDES 
product  model. 


Tolerancina  Modeling  Experiences  -  William  B.  Burkett 
1.  Introduction 

This  article  is  a  summary  of  the  experiences  garnered  by  the 
Tolerancing  Application  Group  (TAG)  from  the  PDES  Initiation 
Task.  It  is  intended  to  represent  the  viewpoint  of  the  TAG  as  a 
whole,  but  some  of  the  thoughts  expressed  herein  are  those  of  the 
author  and  may  or  may  not  reflect  the  feelings  of  the  entire 
committee. 


One  of  the  objectives  of  the  PDES  Initiation  Task  was  to 
serve  as  an  educational  prototype  of  a  working  PDES  organization. 
The  intent  of  this  article  is  to  report  on  the  lessons  learned” 
from  that  task.  The  topics  covered  here  will  start  with  the 
generl  procedure  followed  by  the  TAG  and  it's  subsequent 
interaction  with  the  Logical  Layer  Committe  (LLC) .  This  will  be 
followed  with  a  discussion  of  the  major  problems  encountered,  a 
list  of  iportant  observations  made,  emd  then  a  s\3mmary  of  the 
entire  process. 


A  description  of  content  of  the  work  of  the  TAG  can  be  found 
in  Section  3.4. 
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The  TAG  was  set  up  as  an  independent  Application  Layer  Group 
to  develop  a  reference  model  of  the  information  required  to 
tolerance  a  3-D  geometric  model  according  to  the  ANSI  and  ISO 
standards  (ANSI  Y14.5M  1982,  ISO  1101,  1660).  The  model  produced 
was  then  delivered  to  the  LLC  emd  a  review  cycle  involving  the 
LLC  jand  the  TAG  was  started  to  monitor  the  cnvers ion/ integration 
process.  Once  the  integrated  model  had  been  validated  by  the 
TAG,  the  TAG'S  task  was  considered  complete. 

The  TAG  first  met  in  early  1985  and  spent  eight  months 
developing  the  first  draft  of  the  Tolerance  Reference  Model 
(TRM) .  Members  of  the  TAG  were  Ron  Bale  (Caterpillar) ,  Bil 
Burkett  (McAir) ,  Bob  Colsher  (IGES  Data  Analysis) ,  and  Spencer 
DePauw  (Caterpillar) .  After  the  TRM  was  delivered  to  the  LLC, 

Mr.  Colsher  and  Mr.  Burkett  spent  the  following  four  months 
supporting  the  LLC's  conversion  and  initial  integration  process. 
During  the  last  three  months  of  the  TAG'S  activity,  Mr.  Burkett 
supported  on  the  LLC's  integration  process  and  reviewed  and 
commented  on  the  tolerancing  subset  of  the  integrated  model. 

There  were  three  tasks  undertaken  by  the  TAG  before  an 
actual  modeling  was  started.  First,  a  charter  was  prepared 
outlining  the  scope  of  the  TAG'S  activities  emd  offering  a 
justification  for  the  approach  taken  by  the  TAG.  The  second  task 
was  a  review  of  the  work  done  by  the  PDDl  project  on  the  subject 
of  tolerances  to  determine  the  suitzdsility  of  that  work  to  the 
needs  of  the  TAG.  The  last  task  was  the  selection  of  a  modeling 
technique  for  the  reference  model.  The  TAG  used  a  modified 
version  of  the  IDEF-l  technique  which  was  actually  an  extension 
to  enhance  the  ability  of  IDEF-1  to  represent  information  (these 
extensions  were  considered  as  "author  conventions"  in  IDEF-1 
terminology  and  originated  from  the  PDDI  project) . 

The  development  of  the  model  consisted  mosty  of  reaching  a 
consensus  on  the  interpretation  of  the  standards  and  how  that 
Interpretation  could  best  be  represented  with  the  modeling 
technique . 

Once  the  TAG  agreed  on  a  "finalized"  version  of  the  TRM  it 
was  delivered  to  John  Zimmerman  (Allied  Bendix)  of  the  LLC.  It 
was  the  LLC's  job  to  convert  the  reference  model  to  a  binary 
Information  Analysis  (lA)  model  and  integrate  it  with  other 
application  reference  models.  From  the  integrated  model, 
entities  were  then  defined  in  Data  Specification  Language  (DSL) . 

As  part  of  the  review  cycle,  there  were  several  in-person 
meetings  and  niuaerous  telephone  conversations  to  verify/validate 
that  the  meaning  expressed  in  the  TRM  was  maintained  as  the  model 
was  converted  to  the  lA  model  and  integrated  with  other  models. 
Each  time  a  new  version  of  the  converted/ integrated  model  was 


produced,  a  copy  was  provided  to  the  TAG  for  review.  The  model 
was  finalized  (as  much  as  possible)  in  early  1986.  The  TAG  did 
not  review  the  DSL  specification  formulation  of  the  tolerancing 
information. 

The  conversion  amd  integration  process  discovered  some 
mistakes  and  unclear  thinking  in  the  orginal  TKM.  The  TAG  made 
use  of  these  discoveries  to  revise  and  correct  the  model.  In 
all,  three  versions  of  the  TRM  were  created. 

3.  Special  Considerations 

There  are  several  factors  which  influenced  the  modeling 
processt  that  should  be  noted.  First  and  most  importamtly,  all 
members  of  the  TAG  were  vezy  well  versed  in  the  subject  area  (the 
ANSI  and  ISO  standards) .  Second,  Mr.  Burkett  was  a  member  of  the 
PDDI  project  and  was  responsible  for  the  approach  to  tolerancing 
taken  by  that  project;  Mr.  Colsher  is  chairman  of  the  IGES 
Drafting  committee  and  responsible  for  the  IGES  approach  to 
dimensioning  and  tolerancing.  Third,  most  members  of  the  TAG 
were  experienced  with  data  modeling  techniques  before  work  was 
started. 


4.  Problems  Experienced 

The  'biggest  problem,  obviously,  was  the  emount  of  .time 
required  to  satisfactorily  complete  the  modeling/ integration 
process.  The  experience  of  the  TAG  and  LLC  held  the  time  spent 
to  a  minimum,  but  the  entire  process  still  took  a  considerable 
length  of  time.  The  TAG  spent  about  as  much  time  in  the  review 
process  (with  the  LLC)  as  it  spent  to  develop  the  origins  TRM. 

The  amount  of  time  that  the  LLC  spent  on  the  conversion  and 
integration  process  outside  of  the  review  process  is  difficult 
for  the  TAG  to  gauge;  a  guess  would  be  that  the  review  process 
constituted  about  ne-quarter  of  the  time  of  the  LLC  spent  on  the 
model . 

Another  problem  that  the  TAG  experienced  during  the 
conversion/ integration  process  also  ceuoe  up  to  a  lesser  degree 
during  the  development  process.  By  modeling  the  seuae  information 
using  two  different  modeling  techniques,  it  was  very  clear  how 
difficult  it  is  for  any  diagreu&atic  technique  to  represent 
imderstanding  of  a  particular  subject  domain.  Hiaman  language 
(and  human  understanding)  is  imprecise  and  inexact  >  diagrams  are 
not.  It  was  very  difficult  to  make  the  mental  leap  from  the 
understanding  that  the  TAG  had  of  the  ANSI  and  ISO  standards  to 
an  expression  of  that  vinderstanding  by  means  of  a  diagram. 

The  last  major  prolem  experienced  by  the  LLC  (it  didn't 
really  affect  the  TAG)  was  the  fact  that  the  TRM  was  very  large, 
looked  complex  and  was,  therefore,  intimidating.  This  was 
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probeibly  the  result  of  overcompensation  on  the  part  of  the  TAG. 
Because  of  past  experience  with  modeling  techniques  of  limited 
expressive  power, the  TAG  attempted  to  get  everything  that  they 
knew  about  the  subject  domain  into  the  model  without  resorting  to 
notes  (such  as  the  fact  that  a  Flatness  tolerance  applies  only  to 
planar  faces) .  As  a  result,  the  model  was  semantically  richer 
(expressed  more  meaning)  than  a  typical  reference  model,  but  it 
was  much  bulkier,  too.  Once  the  LLC  became  familiar  with  the 
model,  the  size  did  not  turn  out  to  be  a  problem  because  the 
model  was  composed  mostly  of  simple,  similar,  consistent 
concepts . 


5.  Important  Observations 

The  following  is  a  list  of  important  observations  made 
during  the  entire  modeling  process.  It  is  basically  an 
unstructured  set  of  observations  reflecting  problems,  benefits, 
solutions,  ideas  which  seemed  to  work  best,  problems  with  the 
content  of  the  model,  and  anything  else  which  seemed  to  be 
relevant. 

o  A  drafting  representation  of  the  tolerancing  information 
based  on  conventional  graphical  symbols  (witness  lines, 
leaders,  text  position,  etc.)  cannot  be  generated  solely  from 
the  information  contained  in  the  reference  model.  Drafting 
is  a  presentation  concern  which  is  "further  away"  from  the 
geometric  model  than  tolerances. 

o  The  Logical  Layer  played  the  role  of  a  model  validator, 
rather  than  a  conceptual  modeler.  Most  of  the 
conceptualization  was  done  at  the  Application  Layer. 

o  Truly  functional  aspects  of  the  PDFS  integrated  conceptual 
model  did  not  at  first  drive  the  Logical  Layer  development 
work.  The  PDES  geometric  entities  at  that  time  did  not  have 
the  necessary  constructs  to  support  the  tolerance  model  (such 
as  topological  constructs) .  (Instead,  much  time  had  been 
spent  on  geometry  and  presentation  reference  models  without 
regard  to  the  needs  of  the  applications.)  However,  the  needs 
expressed  in  the  THH  were  eventually  satisifed  by  the  work  of 
the  LLC. 

o  The  T2^  was  very  "proactive".  It  described  the  subject 
domain  and  contained  well  defined  "links"  to  the  integrated 
model.  It  did  not  define  geometry,  yet  it  made  certain 
demands  of  it  (i.e.  topology). 

o  The  fact  that  two  sxibject  experts  were  present  during  the 
review  process  proved  to  be  very  valuable.  Multiple  points 
of  view  allowed  ideas  to  be  played  off  of  one  another  and 
resulted  in  a  more  "accurate"  model  which  was  arrived  at  more 
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quickly.  A  single  expert  presents  only  a  sigle  viewpoint,  so 
the  dotible  coverage  was  very  beneficial. 

o  The  TRM  was  veil  thought  out  beforehand  so  there  wasn't  much 
ad  hoc  application  modeling  being  done  during  the  review 
sessions.  This  allowed  more  time  to  be  devoted  to  the 
understanding  and  conversion  of  the  model.  This  is  not  to 
say  that  the  review  process  (conversion  and  integration) 
didn't  uncover  some  bugs  in  the  THM;  that  process  did  prompt 
several  revisions  of  the  TRM. 

o  Knowledge  of  modeling  was  a  key  ingredient  to  the 

communication  between  the  TAG  and  the  LLC  during  the  review 
cycle.  By  the  time  the  last  reviews  were  taking  place,  the 
TAG  was  reviewing  the  LLC's  ZA  models. 

6.  Summary 

Overall,  the  process  followed  by  the  TAG  and  the  LLC  seems 
to  have  worked  qpiite  well  and  with  a  little  experience  (and  more 
than  a  little  resources)  could  be  used  on  a  larger  scale.  Four 
words  succinctly  summarize  the  process:  Compose;  Decompose; 
Integrate;  and  Recompose. 

The  use  of  two  data  modeling  techniques  to  support  this 
process  was  more  a  boon  them  a  bane.  Each  technique  has  inherent 
problems  with  expressiveness  and  understandability,  but  the  use 
of  both  minimize  the  effects  of  the  problems.  The  conversion 
process  actually  makes  the  models  better  because  the  weaknesses 
of  one  technique  are  compensated  by  the  strengths  of  the  other, 
thereby  xincovering  bugs  in  the  original  model.  Perhaps  in  the 
future  when  everyone  is  an  expert  modeler,  one  technique  will 
suffice.  Curently,  we  don't  understand  either  technique  well 
enough  to  fulfill  our  needs. 

The  conversion  process  forced  the  subject  experts  to  dot 
their  ''i'"s  and  cross  their  "f's.  It  was  realized  that  the 
xinderstanding  of  the  subject  domain  is  inexact,  incomplete  and 
often  contradictory.  The  precision  of  the  modeling  technique 
forces  a  formalization  and  rigor  in  the  understanding  of 
information  that  words  cannot  convey. 

The  biggest  weakness  of  the  entire  process  and  the  source  of 
most  of  the  problems  are  the  tools  used  to  support  it.  The  tools 
we  have  are  good  and  are  a  big  improvement  over  what  was 
previously  done,  but  they  still  have  problems  which  make  them 
difficult  to  use.  Automated  tools  might  help,  if  only  for 
generating  graphics. 

The  only  immediate  solution  for  the  problems  encoiintered 
during  the  work,  of  course,  is  experience.  This  problem  is  a 
problem  of  any  modeling  technique  and  the  best  model  is  at  best  a 
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best  guess.  The  biggest  obstacle  that  a  new  modeler  must 
overcome  is  the  flustered  feeling  that  the  ambiguity  of  the  job 
can  cause.  The  solution  is  simply  to  ignore  it;  there  is  no 
"right"  way. 

As  for  the  time  resource  problem,  it  will  become  less  of  a 
problem  as  people  become  better  modelers  and  better  understand 
their  svibject  domain.  The  entire  process  will  still  taOce  a 
significant  amount  of  time,  but  it  could  be  considered  an 
investment  in  a  common  understanding  of  am  subject  domain.  A 
common  understanding  improves  both  the  completeness  amd  the  ease 
of  commxinication,  and  that  is  what  we're  all  after,  right? 

FEM  Modeling  Experiences  ~  w.  R.  Freeman 

I  applaud  the  overall  approach  to  the  creation  of  PDES,  with 
the  three  layer  architecture,  and  the  use  of  application  experts 
to  initially  define  their  "universes".  Combing  this  with  the 
integration  at  the  logical  layer,  and  definition  of  the  physical 
file  format  AFTER  the  logical  layer  is  completed  gives  a  feeling 
of  a  solid,  sensible  methodology.  This  methodology  is 
innovative,  and  if  carried  out  as  presented  should  result  in  a 
consistent  standards  document  with  a  relatively  small,  non- 
repetitive  list  of  flexible  entities.  There  are  a  few  flaws,  but 
they  can  probably  be  worked  with  if  the  project  directors  will 
realize  the  limitations  and  plan  and  schedule  the  process  to  tzdce 
them  into  account  rather  than  force  the  methodology  to  fit  into  a 
timetable.  This  is  difficult  with  a  volunteer  organization,  but 
critical  to  achieve  the  advantages  expected  from  the  modeling 
approach.  I  hope  that  it  is  possible  to  remain  true  to  the 
original  process,  even  with  the  difficulties. 

The  primary  problem  at  the  application  committee  level  is 
actually  getting  the  members  to  think  "in  the  information  plane". 
The  normal  day-to-day  work  of  most  committee  members  is  with 
processes  -  that  is,  getting  things  accomplished;  doing  things  to 
other  things,  and  with  things.  We  can  imagine  that  these 
processes  occur  in  a  two-dimensional  plane;  let  us  call  it  the 
' process  plane ' .  The  *  information  plane '  is  where  information 
models  reside,  and  is  orthogonal  to  the  'process  Information 
plane',  and  KEEPING  THEM  THERE  is  the  real  problem.  Countless 
hoiirs  have  been  spent  discussing  important  issues  (in  the  field 
being  modeled)  that  are  irrelevant  to  the  way  that  information 
about  that  field  is  related.  The  problem  of  not  understanding 
the  difference  between  the  process  of  doing  FEM  and  the  list  of 
entities  required  to  carry  out  that  process,  amd  their 
interrelationships  keeps  coming  up.  If  it  seems  that  "important 
issues"  shouldn't  be  "irrelevemt",  remember  that  the  model  is  of 
data  and  the  relationships  between  data,  and  NOT  of  the  process 
of  finite  element  modeling  and  analysis. 
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It  is  critically  important  that  at  least  one  person  with  a 
proper  grasp  of  Information  modeling  attend  the  majority  (all  is 
better)  of  committee  meetings  when  a  model  is  being  formulated. 
This  is  especially  important  with  the  long  hiatus  between 
meetings,  and  the  variable  membership  of  the  committees. 
Considerable  time  was  spent  each  time  attempting  to  bring  new 
members  up  to  speed  with  IDEF,  and  keeping  forgetful  old  members 
in  the  information  plane.  If  no  reliable  and  respected  modeling 
semi-expert  is  available,  much  time  will  be  wasted  producing  a 
model  of  a  process,  not  an  information  model.  This  is  almost 
guaranteed. 

The  second  potential  problem  seen  with  the  methodology  is 
the  error  of  trying  to  run  all  three  layers  simultaneously.  Given 
the  time  constraints  and  the  exploratory  nature  of  the  PDSS 
Initiation  Effort,  it  was  acceptable  and  probably  necessary  to 
run  all  three  processes  simultaneously.  However,  I  would  object 
strongly  to  running  the  full  scale  PDES  project  on  the  same 
schedule.  If  a  technically  solid  PDES  with  good  long  term 
viability  is  to  be  developed,  adherence  to  the  methodical  and 
systematic  approach  offered  by  the  three  schema  architecture  is 
important. 

The  third  problem  with  PDES  is  conceptual.  While  I  support 
the  concepts  and  goals  expressed  by  many  of  the  people 
contributing  to  this  effort,  I  strongly  suspect  that  not  one  in 
five  of  the  committee  members  has  a  real  feel  for  the  size  of  the 
task  being  undertaken.  There  has  probably  been  no  previous 
attempt  to  organize  the  world  over  such  a  broad  range  of 
applications.  I'm  fairly  s^xre  that  the  project  is  much  larger 
than  most  individual  applications  experts  understand,  and  that 
without  proper  understanding  of  the  scope  of  this  project  it  may 
floimder  or  even  fail.  If  the  project  is  intentionally  limited 
in  scope  it  could  succeed.  If  the  PDES  project  is  kept  as  is 
defined  (rather  open-endedly) ,  AMO  SCHEDULING  IS  OVERLY 
OPTIMISTIC,  the  appearance  of  failure  will  be  the  result  of 
regardless  of  the  quality  of  the  work.  The  scope  of  the  project 
is  great,  and  realistic  scheduling  is  needed,  rather  than 
limiting  the  scope. 

The  need  for  high  level  plaxming  on  scope  is  in  addition  to 
the  need  for  a  better  understanding  of  the  FUNDAMENTAL 
interrelationships  between  different  technology  areas  encompassed 
by  the  PDES  project.  This  need  was  first  (and  far  more 
competently)  addressed  at  the  Knoxville  IGES  meeting  by  Roger 
Gale,  and  I  recommend  that  his  counsel  on  this  subject  be  sought. 

On  the  plus  side,  the  natural  language  quality  assurance 
loop  was  used  successfully  to  verify  both  the  veracity  of  the 
modeling  for  FEM,  and  to  validate  the  conversion  from  IDEF  to  lA 
modeling  language.  This  is  a  valuable  tool,  and  should  be  used 
in  the  future. 
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Liaison  between  the  application  comnittees  and  the  logical 
layer  integration  personnel  is  very  important.  I  frequently 
interacted  with  John  Zimmerman  during  the  Initiation  Effort,  and 
it  is  amazing  how  severe  the  "can't  see  the  forest  for  the  trees'* 
problem  can  be.  Application  committee  members  frequently  feel 
that  a  model  is  clear  when  it  is  not,  and  logical  layer 
integration  has  a  tendency  to  inadvertantly  modify  or  even 
destroy  relationships.  Liaison  between  these  areas  should  be 
close  and  occur  frequently. 

Overall,  the  POES  modeling  approach  is  a  real  advancement 
over  the  previous  haphazard,  cut  and  past  approach  to  a  standard. 
A  good  bit  of  project  leadership  and  committment  by  qualified 
information  modeling  experts  is  required  to  make  it  work.  I 
sincerely  hope  that  the  project  is  successful  since  it  will  be  a 
real  landmark  of  integration,  communication,  and  order  in  a 
disorderly  world. 
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PDES  Initiation 


Logical  L^yer  Methodology 
Principal  Author:  John  Zimmerman/  Allied/Bendix  Aerospace,  Kansas  City 


The  primary  mission  of  the  Logical  Layer  Initiation  Effort  is  to  develop 
the  definition  of  the  logical  entities  required  to  meet  the  needs  of  all 
applications  within  the  initiation  scope.  This  includes  "generic  entities" 
which  are  required  by  two  or  more  applications  and  "application  specific 
entities"  which  are  used  in  only  one  application  area.  This  set  of 
entities  and  their  relationships  is  referred  to  as  the  conceptual  schema. 

The  Primary  goal  of  the  PDES  Initiation  Logical  Layer  Methodology  is  to 
guide  the  Logical  Layer  Initiation  Effort  in  the  development  of  the 
conceptual  schema  for  ^sk  1  and  Task  2  of  the  PDES  Initiation  Effort  as 
described  in  the  PDES  Logical  Layer  Charter. 

The  following  are  key  success  factors  for  this  methodology: 

1.  Maximize  usage  of  state-of-the>art  conceptual  modelling  techniques  and 
tools. 

2.  Support  the  integration  of  the  three  PDES  architectural  layers 
(application,  logical,  and  physical)  as  described  in  "The  Second  PISS 
Report" . 

3.  Maximize  the  usage  of  hiznan  resources  in  development  of  the  conceptual 
schema  by  defining  and  establishing  project  roles. 

4.  Simplify  the  methodology  as  much  as  possible. 

5.  Give  the  methodology  growth  potential  so  that  it  can  support  future 
.  PISS  efforts. 

6.  Maximize  the  potential  of  the  conceptual  schema  to  serve  as  a  central 
resource  from  which  all  other  PDES  forms  can  be  computed. 


Methodology  Overview 

Refer  to  the  accompanying  figure  for  a  graphical  overview  of  the 
methodology.  The  numbering  of  the  models  is  consistent  with  the  US 
Position  paper  "Reference  Models,  Development  Methodology,  and  Bitity 
Subsets  for  STEP"  submitted  to  1SO/TC184/SC4/WG1  by  the  US  TAG. 

The  methodology  is  broken  into  three  phases: 

PHASE  1;  Pre-conceptualization.  In  this  phase  all  application  area 
reference  models,  regardless  of  modelling  form,  are  reduced  to  binary  form 
to  maximize  potential  for  conceptialization  and  integration.  When  these 
binary  models  are  verified  against  the  original  application  area -model  they 
are  considered  "qualified". 


PHASE  2;  Conceptualization  and  Integration.  In  this  phase  conceptual 
entities  and  relationships  are  discovered.  ArTlLnteg rated  conceptual  nodel 
is  built  from  which  can  be  derived  (via  mappings)  any  application  area 
reference  model.  A  conceptual  architecture  will  be  built  that  models  all 
conceptual  categories.  This  architecture  will  be  stored  in  a  dictionary 
which  will  be  developed  in  this  stage.  It  is  in  this  phase  that  the 
maximum  potential  of  the  conceptual  schema  will  be  realized. 

PHASE  3;  Post-Conceptualization.  In  this  phase  the  binary  cwiceptual 
schema  will  be  conditioned  in  preparation  for  development  of  the  physical 
file  format.  The  conceptual  schema  is  grouped  into  a  nested  record  form 
called  Data  Specification  Language  (DSL).  This  DSL  form  is  the  ultimate 
deliverable  to  the  physical  file  layer.  The  ultimate  source  of  the  DSL 
will  always  be  the  binary  conceptual  schema. 


Methodology  Details 
PHASE  1:  Pre-conceptualization 

Goal:  To  maximize  the  conceptualization  and  integration  potential  of  the 
application  area  models. 

Input:  Application  area  reference  models. 

Deliverable:  A  computerized  binary  model  verified  to  be  equivalent  to  the 
original  application  area  reference  model. 

Description:  This  phase  of  the  methodology  conditions  the  application  area 
reference  model  in  preparation  for  owceptualization  and  integration.  In 
the  PDES  Initiation  Effort  application  area  reference  models  may  be  of  any 
form  that  has  a  reasonable  degree  of  rigor.  The  conditioning  process 
converts  these  diverse  forms  into  a  single  standard  semantic  form.  The 
standard  semantic  form  is  the  binary  model.  Specifically,  Nijssen's 
Information  Analysis  Model  (NIAN)  will  be  used. 

All  application  area  reference  models  are  manually  reduced  to  binary  form 
and  entered  into  an  electronic  data  base  (CDC's  Information  Anal>:iis 
Support  Tool  -  lAST).  This  model  database  is  echoed  back  to  the 
application  area  in  the  form  of  natural  language  sentences  derived  manually 
from  the  binary  model  and  in  computer'-generated  relational  structures.  The 
relational  structures  are  used  for  the  validation  of  binary  models  that 
have  been  translated  from  record-oriented  application  area  models.  The 
natural  language  sentences  are  returned  to  the  application  area  for 
approval.  The  binary  model  is  considered  to  be  "qualified"  when  the 
natural  language  sentences  are  approved  and  the  relational  structures  are 
verified  to  be  equivalent  to  the  original  record-oriented  model.  It  is 
presumed  that  most  application  area  reference  models  will  be  record  or 
relational ly  oriented. 

Even  though  the  computer  generated  relational  model  may  be. useful  in 
follow-on  PDES  efforts,  its  only  i»e  in  the  Initiation  Effort  is  the 
validation  of  record-oriented  reference  models.  The  deliverable  of  this 
phase  is  the  binary  conceptual  model. 


PHASE  1  roles  identified: 


1.  Model  translators 

2.  Model  software  siqsport  tool  technician 

3.  Liasion  between  application  and  logical  layer  to  sxipport  natural 
language  verification. 

4.  Data  modelling  expert  who  is  able  to  verify  equivalency  of  the  computed 
form  with  the  original  application  area  reference  models. 

PHASE  2 I  Conceptialization  and  Integration 

Goal:  lb  build  the  conceptual  schema  and  maximize  its  potential  as  a 

central  resource  in  the  PEXS  Initiation  Effort  and  to  develop  a  conceptual 
dictionary  tool  to  hold  t' a  components  of  a  conceptual  architecture. 

Input:  ^alified  binary  models  of  the  application  areas. 

Deliverable:  A  computerized  conceptual  schema  in  binary  form;  and  a 

computerized  data  dictionary  containing  the  conceptual  architecture  and 
conceptual- to-applicat ion  area  mappings. 

Description:  It  is  in  this  phase  that  the  actual  concepttiali ration  and 

integration  occxirs.  The  reader  is  encouraged  to  refer  to  Appendix  A  which 
is  an  excerpt  from  "The  Second  PDES  Report".  It  overviews  and  describes 
the  three  layer  architecture.  This  phase  is  the  most  challenging  of  the 
three  phases  of  the  logical  layer  methodology.  It  is  from  this  phase  that 
the  crucial  aspects  of  extensibility^  stability^  resilience,  and  technology 
independence  will  be  confronted.  Some  cultural  resistance  to  this  phase  is 
to  be  expected  as  it  seems  to  draw  out  the  process  of  getting  to  the 
ultimate  PI£S  deliverable,  the  physical  file  format. 

As  an  initiating  effort,  this  phase  will  start  with  popular  concepts  and 
notions  of  conceptual  schema  that  have  been  derived  from  ANSI/X3/SPARC, 
ISO/TC97/SC5Arc3,  NASA  IPAD,  and  PDDI.  The  logical  layer  team  realizes 
that  conceptualization  across  the  broad  spectrum  of  product  data 
represented  in  the  application  models  is  a  new  area  for  standards  work. 
The  team  also  realizes  that  the  conceptualization  of  engineering  and 
manufacturing  artifacts  is  fairly  new.  The  team  expects  to  adapt  the 
principles  of  conceptualization  as  they  apply  to  business  systems  to 
engineering  and  manufacturing  artifacts  as  much  as  possible,  but  realizes 
that  new  conceptualization  principles  must  be  developed. 

PHASE  2  is  divided  into  two  sub-phases,  PHASE  2A  and  PHASE  2B.  PHASE  2A  is 
concerned  with  the  building  of  the  conceptual  schema  from  detailed 
application  area  reference  models  (in  a  general  sense  a  bottom-up  process). 
PHASE  2B  deals  with  a  conceptual  schema  architecture  that  will  give 
high-level  structure  for  the  guidance  of  PHASE  2A  activities  (in  a  general 
sense  a  top-down  process) .  It  is  anticipated  that  the  software  support 
tools  for  PHASE  2A  and  2B  will  be  separate  but  manually  coordinated.  The 
primary  support  tool  for  PHASE  2A  will  be  lAST.  The  primary  support  tool 
for  RASE  2B  may  possibly  be  a  relational  data  base  system  such  as  RIM. 


PHASE  ^  Description:  The  construction  of  a  conceptual  schema  is  not  a 

w©ll-<3efined  process  and  this  methodology  will  serve  only  as  a  guide. 

The  following  tasks  are  identified: 

1-  Develop  a  set  of  entity  categories.  To  the  greatest  extent  possible 
these  categories  will  be  generic  in  that  they  may  be  used  across  a 
broad  set  of  applications.  These  categories  can  be  discovered  as  the 
qualified  application  reference  models  are  being  reviewed  (bottom-up) 
or  an  initial  set  can  be  adopted  provisionally  from  other  sources  such 
as  PDDI. 

2.  Develop  a  set  of  structural  categories.  A  structure  in  this  case  is  a 
recognizable  pattern  of  inter-related  entities  that  appears  in  multiple 
application  area  models.  The  conceptual  schema  will  consist  of  generic 
entities,  generic  structures,  and  application  specific  structures. 

3.  Examine  each  qualified  application  area  model  and  attempt  to  break  it 
completely  into  generic  entities,  generic  structures,  and  application 
specific  entities.  This  partitioning  of  the  application  area  model  is 
recorded  in  the  data  dictionary  (this  tool  is  created  by  PHASE  2B 
activities. ) . 

4.  Once  the  application  area  model  has  been  completely  translated  into  the 
conceptual  schema,  logical  layer  workers  in  conjunction  with 
application  layer  workers  verify  that  the  original  application  area 
model  can  be  recovered.  It  is  the  job  of  the  logical  layer  worker  to 
be  familiar  with  the  generic  enti tiles  and  structures.  It  is  the  job 
of  the  application  area  worker  to  find  a  best  fit  for  his  application 
entities.  A  cooperation  effort  between  logical  and  application  workers 
is  crucial  in  this  task. 

5.  Once  the  application  area  model  is  verified  to  be  recoverable  from  the 
conceptual  schema  all  mappings  must  be  defined  and  recorded  in  the 
dictionary.  The  logical  layer  team  may  possibly  not  be  concerned  in 
the  Initiation  Effort  about  formally  defining  these  mappings  although 
in  future  PDES  efforts  it  will  become  more  important.  In  this  case 
narrative  sentences  may  suffice. 

6.  Make  any  adjiwtments  to  the  conceptiaal  schema  (hopefully  an  addition  of 
a  new  generic  entity,  not  a  change  to  an  existing  generic  entity).  It 
may  be  necessary  to  regressively  test  all  previous  application  area 
models  for  recoverability  after  a  major  change  to  the  conceptual 
schema . 


PHASE  2B  Description:  This  activity  is  similar  to  the  strategic  data 
planning  activity  for  the  development  of  a  large  integrated  business 
information  system.  The  tasks  are  as  follows: 

1.  Adopt  a  conceptual  schema  architecture.  Appendix  B  is  em  excerpt  from 
the  US  position  paper  "Reference  Models,  Development  Methodology,  and 
Entity  Subsets  for  STEP"  8\±jmitted  to  IS0/TC184/SC4AW.  The  subsets 
referred  to  in  this  paper  are  the  major  architectural  components  we  are 
looking  for.  These  architectural  components  will  be  dictionary 
categories.  Refer  to  Appendix  B  for  a  complete  rationalization  for  the 
need  of  a  conceptual  schema  architecture. 

2.  Develop  a  conceptual  dictionary  tool  to  hold  the  architectural 
components.  It  would  be  advantageous  if  this  dictionary  were  an 
integral  part  of  the  I  AST  but  the  PDES  Initiation  Effort  delivery 
schedules  will  not  permit  this.  It  is  suggested  that  a  simple 
relational  tool  such  as  RIM  be  used  provisionally.  The  following 
dictionary  categories  would  be  a  start:  Life  Cycle  Stage,  Discipline, 
Functional  Area,  Application  Area,  Class,  Entity,  Version.  This 
initial  set  of  categories  should  greatly  assist  in  giving  the 
conceptual  schema  development  project  direction  and  cohesiveness.  An 
effort  should  be  made  to  keep  the  nunber  of  dictionary  categories  as 
small  as  possible.  Obviously  new  categories  must  be  added  to  cover  the 
mapping  of  the  conceptual  schema  to  application  area  models. 

PHASE  2  roles  identified: 

1.  Model  sofb^re  support  tool  technician 

2.  Liason  between  application  layer  and  logical  layer 

3.  Dictionary  administrator 

4.  Conceptual  model  administrator 

5.  Data  architect  who  has  broad  )Qiowledge  of  engineering  and  manufacturing 
life  cycle,  disciplines,  and  applications. 

6.  Data  analyst 

PHASE  3:  Post-Concept\ialization 

Goal :  To  condition  the  conceptiial  schema  in  preparation  for  conversion  to 
the  PDES  exchange  format. 

Input:  The  binary  conceptual  schema  and  mappings  to  application  area 

mo^ls. 

Deliverable:  A  complete  specification  of  the  conceptual  schema  in  Data 

Specification  Language  (DSL). 

PHASE  3  Description:  The  purpose  of  this  phase  is  to  convert  .the  binary 
conceptiaal  schema  into  a  grouped  logical  record  form  (a  structural  form) . 
This  form  is  still  neutral  as  it  has  not  yet  been  committed  to  a  physical 
form.  The  Data  Specification  Language  (DSL)  has  been  chosen  as  the  PDES 


Initiation  Effort  standard  structural  form.  It  was  chosen  because  its  form 
(nested  array)  naturally  models  the  hierarchical  structure  of  most 
engineering  and  mainfacturing  artifacts.  It  is  also  a  compact  textual  form 
suitable  for  docunentation. 

The  major  task  is  the  actual  conversion  of  the  binary  conceptual  schema 
into  DSL.  For  the  PDES  Initiation  Effort  this  will  be  done  manually  but  it 
is  suggested  for  follow  on  efforts  that  this  conversion  be  automated. 

The  DSL  specification  of  the  conceptual  schema  represents  the  official 
documentation,  ho^^ver  the  binary  conceptual  schema  will  always  be  the 
source  from  which  the  DSL  specification  is  generated.  The  binary 
conceptual  schema  is  the  principle  resource  for  the  Initiation  Effort. 

PHASE  3  role  identified: 

1.  Translator  from  binary  conceptual  schema  to  DSL 


Appendix  A 
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THE  AACHTTECTURE  OP  THE  PDES 


The  task  of  developing  a  data  standard  for  industries  using  CAD/CAM  is  a 
huge  undertaking.  The  problem  must  be  broken  down  into  smaller  pieces  in 
order  to  make  progress.  Modularization  is  the  separation  of  a  process  into 
small,  separate  functions  with  precise  interfaces  between  the  functions. 
This  separation  makes  each  function  manageable  and  eases  maintenance 
since  changes  can  be  isolated  to  a  specific  function.  Modularization 
provides  flexibility  to  make  changes  since,  as  long  as  the  interface  between 
functions  remains  the  same,  one  function  cannot  tell  if  another  has  been 
changed  or  even  replaced.  Modularization  of  the  development  process  is  a 
philosophy  recommended  for  the  PDES  development.  That  is,  different 
groups  will  be  tasked  with  different  functions  of  the  design  process.  The 
function  of  data  analysis  and  design  will  be  partitioned  into  three  parts 
based  on  the  level  of  abstraction  of  the  data.  Thus,  the  application 
information  will  be  separated  from  the  conceptual  entity  definition  which 
will  be  separated  from  the  physical  definition.  Each  such  partition  will  be 
called  a  layer. 

As  alluded  to  above,  the  PDES  will  be  structured  into  a  three  layer 
architecture.  These  layers  correspond  almost  identically  with  the  layers  of 
schema  in  the  ANS1/X3/SPARC  three  schema  architecture  (cf.  appendix 
C.1.1)  for  defining  and  implementing  data  bases.  The  layers  are  described 
in  the  following  sections  and  illustrated  by  figure  4-3. 

4.4.1  Applieation/User  layer 

In  the  chosen  architecture,  the  top  layer  is  the  user  or  application  layer. 
This  is  the  layer  at  which  the  ultimate  user  lives  and  thinks.  He  formulates 
his  dau  requirements  in  his  own  terms  stating  concisely  what  he  needs.  He 
draws  from  his  own  experience  and  from  the  established  terms, 
conventions,  techniques,  and  methodologies  of  his  discipline.  He  isn't 
concerned  with  the  number  of  different  ways  that  a  single  thing,  event,  or 
phenomenon  can  be  represented.  He  isn't  concerned  with  analogous  notions 
used  by  different  applications.  For  example,  he  doesn't  eare-thit  electrical 
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Figure  4-3.  Three  Layer  POES  Architecture 


and  piping  networks  share  much  in  common.  The  different  application 
groups  such  as  Electrical  Products  or  Finite  Element  Modeling  define  the 
information  relevant  to  their  application  and  model  the  interrelationships 
that  exist  between  the  informational  entities.  This  information  is  defined 
by  using  a  reference  or  information  model.  The  reference  model  helps 
structxire  and  validate  the  data  in  the  application. 

This  layer  of  the  Standard  contains  as  many  different  applications  and 
entities  within  those  appb'cations  as  there  is  apparent  need  for. 

.4.2  Logical/Cooceptual  layer 

The  second  layer  is  the  logical  or  conceptual  layer.  This  is  where  the  data 
content  for  the  set  of  generic  entities  is  defined.  This  set  should  be  a 
normalized,  minimumly  redundant  set  (cf.  sec.  4.3}  that  supports  the 
information  defined  by  the  applications. 

At  this  layer,  logical  commonality  will  be  sought  across  all  applications. 
Things,  events,  and  phenomena  which  are  identical  except  for  the  renaming 
of  components  will  be  treated  as  being  logically  identical.  Thus  the 
connectivity  of  a  piping  network  and  an  electrical  network  will  be 
considered  logically  identical.  Also  at  this  layer,  there  will  be  exactly  one 
way,  not  several,  to  represent  a  directed  line  segment,  perhaps  by  a  point 
together  with  a  direction  vector. 

At  this  layer,  complex  things,  events,  and  phenomena  will  be  constructed 
of  less  complex  things,  events,  and  phenomena  whenever  possible.  The 
purpose  is  to  maximize  the  utilization  of  conversion  processors  for  simpler 
entities  in  the  process  of  converting  a  complex  entity. 

Similarities  in  the  information  requirements  of  different  applications  will 
be  integrated  into  single  conceptual  entities.  The  integration  of  different 
application  requirements  will  control  the  definition  of  redundant  entities 
and  will  help  to  ensure  a  consistent,  coherent  entity  set. 
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The  entity  definitions  at  this  layer  will  be  in  a  logical  form.  That  is,  the 
data  content  of  an  entity  will  be  defined  but  not  the  physical  format.  As 
described  in  Section  4.2,  a  definition  language  will  be  defined  in  which  the 
entities  will  be  specified.  This  language  will  be  a  formal,  rigorous  language 
which  will  help  reduce  ambiguity  as  is  present  in  the  IGES.  In  addition, 
reference  models  will  be  built  to  verify  consistency  among  the  definitions. 

The  data  content  of  the  set  of  application-specific  entities  will  also  be 
defined  at  this  layer.  These  entities  will  be  defined  in  the  same  rigorous 
manner  as  the  generic  entities  above,  that  is  with  their  data  content 
specified  using  a  formal  definition  language  and  reference  models. 

It  is  expected  that  the  concepts  of  the  logical  layer  will  be  organized  as 
the  product  data  itself  is  organized.  This  organization  is  discussed  in 
section  2.1  and  is  outlined  in  figure  2-1. 

4.4.3  Physaeal/lntemal  Layer 

The  bottom  layer  is  the  physical  or  internal  layer.  This  layer  contains  one 
or  more  actual  file  format  definitions.  It  consists  of  the  description  of  the 
sections,  records,  fields,  sequencing,  and  associated  formats  for  the 
exchange  file.  Again,  a  formal  definition  language  will  be  used  to  reduce 
ambiguity.  A  reference  model  will  be  built  for  each  format  definition. 

Since  the  content  is  separated  from  the  format,  multiple  formats  can  be 
defined  for  logical  entity  definitions  which  only  affect  the  read/write 
routines  of  a  processor.  Thus  the  majority  of  a  PDES  processor  will  be 
independent  of  the  file  format. 


Appendix  6 


A  EfJC'  /  K 


6.0  Subsets  of  the  Conceptual  Schema 

One  or  more  mechanisms  are  required  within  the  Conceptual  Schema  for 
defining  subsets  of  entities.  These  will  be  used  in  a  variety  of  ways  for 
creating,  understanding  and  using  STEP. 

6.1  Requirements  for  Subsets 


6.1.1  Hunan  Understanding  of  the  Standard 

0  To  understand  any  large  collection  of  facts  (such  as  the 
Conceptual  Schema),  a  human  must  categorize  the  facts  into' 
collections  (subsets)  which  are  intellectually  manageable. 
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0  The  nanes  on  the  subsets  can  be  used  to  understand  the  scope  of 
the  collection. 

0  Subsets  for  the  Conceptual  Schema  act  as  a  directory  for  users 
or  logical  modelers  (developers)  to  find  existing  entities  that 
perform  a  function. 

0  An  entity  can  be  better  understood  if  other  members  of  its 
Subset  and  the  nature  of  the  subset  are  known. 

0  Users  can  match  an  application  with  others  which  can  do  the  same 
- 

or  related  jobs  based  upon  Conceptual  Schema  subsets. 

6.1.2  Functional  Requirements 

0  Subsets  provide  an  abbreviation  efficiency  within  the  reference 
models.  For  example,  when  a  certain  attribute  may  be  any  valid 
curve,  we  can  specify  the  class  "CURVE"*  rather  than  enumerating 
all  valid  curves. 

#  • 

0  Schema  management  procedures  nay  be  used  to  propagate  common 
attributes  to  every  member  of  a  class. 

0  Subsets  can  be  used  by  validation  checking  software  to  certify 
translators  and  other  applications. 

6.1.3  Management  of  Development 

0  Subsets  of  the  Conceptual  Schema  represent  subsets  of  the  work 
required  in  developing  the  standard.  They  can  be  used  to  define 
the  scope,  development  milestones,  and  subdivision  of  labor  and 
expertise. 

0  A  uniform  system  of  subsets  may  be  useful  in  recognizing  voids 
in  the  standard.  For  example,  if  analysis  reference  models  had 
been  defined  for  mechanical  and  architectural  disciplines,  but 
not  for  electrical,  the  void  would  be  obvious. 
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0  Versions  of  the  standard  could  be  regarded  as  natural, 
time-dependent,  subsets. 

6.2  Identification  of  Subsets 

The  best  method  of  subset  identification  would  be  to  exercise  the 
methodology  discussed  in  Section  4  and  use  logical  layer  processing  to  help 
discover  natural  functional  subsets.  However,  logical  layer  processing 
would  be  enhanced  by  a  pre-existing,  coordinated  set  of  subsets  selected 
from  common  knowledge  of  data,  functions,  and  applications  within  the 
CAD/CAM  community.  This  set  will  undergo  continual  review  and  updating  as 
the  standard  develops  -in  the  logical  layer  deliberation. 

6.3  Proposed  Subset  Types  of  the  Conceptual  Schema 

To  address  all  of  the  above,  a  network  of  subsets  of  several  types  are 
required.  The  structural  relationships  between  the  types  is  depicted  in 
Figure  3.  The  types  are  defined  as  follows: 

Versions  -  Time  sequenced  sets  of  the  entire  standard.  Each 

# 

version  would  contain  all  entities  and  subset 
structures  valid  in  a  particular  release  of  the 
standard. 

Functional  Area  -  A  high  level  set  of  application  area  subsets  can  be 

used  for  a  particular  function.  It  can  be  regarded  as 
a  two  dimensional  matrix  of  engineering  disciplines  and 
product  life  cycle  as  shown  in  Figure  4.  Each  cell  on 
the  matrix  defines  a  functional  area  and  may  contain 
multiple  application  area  subsets.  This  chart  and 
concept  is  adapted  from  document  (4).  In  that  document 
the  matrix  is  part  of  a  4  dimensional  matrix  called 
"Level".  The  term  "Level"  derived  primarily  from 
another  dimension  which  classified  geometric 
complexity.  That  concept  is  part  of  a  following'class 
structure. 
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FUNCTIONAL  AREAS 


Application  Area  -  A  set  of  entities  and  classes  for  modeling  the  concepts 

of  a  particular  application  (such  as  forging  design)  or 
related  applications  (such  as  forging  design  and 
manufacture).  Application  area  subsets  may  apply  to 
multiple  Functional  Areas;  e.g.  FEM  Application  Area 
will  be  used  for  analysis  in  several  disciplines.  ^ 
application  area  may  contain  other  application  areas; 
e.g.,  manufacturing  forging  area  may  be  different  from 
but  nay  include  design  forging  area.  A  combination  of 
version  and  application  area  could  be  used  to  specify 
capability  of  an  application. 

Class  -  A  set  of  entities  or  classes  (but  not  both)  which  are 
semanticly  similar.  Each  entity  is  contained  in 
exactly  one  class.  Each  class  is  contained  in  zero  or 
one  higher  level  class. 

A  class  may  be  generic  or  application  area  specific. 
This  means  it  may  be  used  in  multiple  application  areas 
or  may  simply  collect  the  entities  which  are  unique  to 
•  a  single  application  area. 

In  Figure  3  the  relations  between  subset  types  and  entities  are 
represented  as  single  diamond  leaders  for  one-to-many  relations  and  double 
diamond  leaders  for  many-to-many  relations. 

See  Appendix  B  for. the  recommended  classes  and  entities  for  STEP. 

6.4  Storino  Subset  Definitions 

One  method  for  defining  subsets  within  the  conceptual  schema  is  the 
"class"  structure  defined  in  the  Data  Specification  Language  in  WGl  N20. 
Additional  methods  may  be  required,  particularly  for  versions. 
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STEP  Classes 


2.1.1 

2.1.2 

2.1.3 

2.1.4 

2.1.5 

Geor.etry/Topol  ocy  ""X 

Tolerance 

Form  Feature 

Part /Assembly 

Administrative  t  Control 

Generic  Design  Classes 

2.1.6 

Constraint  Dependency 

^  (Used  by  Multiple  Life 

2.1.7 

Materi  al 

Cycle  Stages) 

2.1.8 

Process 

2.1.9 

Instances 

J 

2.2.1 

Analysis 

• 

2.2.2 

Manufacturing 

1 

0  Planning 

0  Fabrication 

1 

1  Classes  for  Specific 

0  Assembly 

Stages  of  Product  Life 

2.2.3 

Quality  Assurance 

Cycles  OR  Specific 

2.2.4 

Testing 

1 

Application  Areas 

2.2.5 

Product  Support 

2.3.1 

Product  Manifestation 

0  Documentation 
0  Drafting 
0  Bill  of  Materials 


0 

0  Display 

2.3.2  Metadata 

2.3.3  Parametric  Design 

2.3.4  Data  Base 

2.3.5  User  Defined  Entities 
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Appendix  C 


Logical  Laver  Content 


Task  1  Deliveredsles 

Cl  Wirefreune  Geometry  Resource  Model 

C2  Presentation  Resource  Model 

C3  Flat  Plate  Mechanical  Part  Discipline  Model 

Task  2  DelivereOales 

C4  Electrical  Schematic  Application  Model 
C5  Tolerancing  Application  Model 
C6  Finite  Element  Modeling  Application  Model 
C7  Topology  Resource  Model 

C8  Geometry^Topology  Associativity  Resource  Model 
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Cl.l  Initial  Model  and  Documentation 
Cl. 2  NIAM  Model 
Cl. 3  DSL  Model 
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October  10th,  1985 


PROPOSED  WIREFRAME  GEOMETRY  FOR  PDES 


Edward  Clapp 
IBM 


The  first  draft  of  this  document  was  the  result  of  the  February 
1985  Cincinnati  meeting  of  the  PDES  Logical  Layer  Initiation  Task 
Group.  The  major  influences  for  this  proposal  were  I6ES  3.0,  the  IGES 
Experimental  Solids  Proposal,  and  the  personal  idiosyncrasies  of  those 
present  at  that  meeting. 

I  have  received  written  comments  from  a  number  of  people,  which  are 
available  as  Curves  and  Surfaces  Committee  docximents  CS85-2  to  CS85-10. 

We  have  also  discussed  it  at  two  IGES  meetings.  Unforttinately  it  has 
not  been  possible  for  me  to  present  it  to  the  ISO  TC184  SC4  WGl,  though 
the  German  delegation  has  extensively  commented  on  it.  All  of  these 
have  been  most  welcome.  My  summary  of  these  comments  and  responses  to 
them  is  document  CSSS -Id. 

This  document  is  the  proposed  wireframe  geometry  for  PDES.  There 
are  changes  but  this  does  not  represent  a  major  technical  revision  of 
the  first  draft  in  terms  of  the  content  of  the  geometry.  I  have  attempt¬ 
ed  to  more  fully  explain  some  of  the  constructs  and  the  reasons  for  them. 
Where  there  was  controversy,  I  have  so  indicated. 

The  entity  set  has  been  divided  into  two  parts.  The  first  is  that 
which  is  explicitly  geometry.  The  other  is  a  collection  of  entities 
needed  to  support  geometry  and  a  discussion  about  the  things  that  we 
need  to  be  able  to  say  symbolically  about  the  geometry.  This  includes 
some  discussion  on  definitions  and  instancing,  external  referencing, 
and  grouping. 

The  text  entity  has  been  dropped  as  the  Presentation  portion  of  PDES 
is  now  well  underway. 

1  think  this  paper  does  address  the  wireframe  portion  of  geometry 
adequately.  It  is  not  complete  in  that; 

-  we  need  some  sort  of  formal  language  to  express  these  constructs 
precisely.  1  have  used  an  informal  Pascal -like  language  here. 

For  the  geometry  of  curves,  this  is  sufficient  to  understand  the 
intent.  For  the  kinds  of  ways  we  need  to  be  able  to  relate  the 
geometric  entities,  it  is  not. 

-  parameterization  of  curves,  needed  to  define  surfaces,  is  in¬ 
complete.  This  will  be  addressed  when  we  start  work  on  surfaces. 

-  2D  offset  curves  can  be  added  when  parameterization  has  been  com¬ 
pleted. 

-  some  mechanism  for  parametric  evaluation  of  geometry  is  needed, 
but  that  is  beyond  the  scope  of  this  effort. 

-  geometric  tolerancing  is  inadequate.  Contributions  from  anyone 
wishing  to  make  them  are  welcome. 
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-  topology  for  B-rep  modeling  needs  to  be  addressed  in  the  context 
of  this  proposal. 

■  also  needed  is  a  general  framework  in  which  these  entities  are 
used;  in  particular  descriptions  of  some  of  the  structural  ent¬ 
ities  such  as  model,  view,  drawing,  and  library. 


The  people  who  helped  most  in  preparing  the  original  document  were: 
Steve  Bodnar,  CDC 
Richar  Fuhr,  Boeing 
Don  Hemmelgam,  ITI 
Tom  Railing,  ITI 
Doug  Schenck,  McDonnell  Douglas 
Chia  Hui  Shih,  SDRC 
Peter  Wilson,  GE 

Subsequently,  J.C.  Kelly  (Sandia),  John  Zimmerman  (Bendix) ,  and 
Paul  Thompson  CCDC)  made  a  number  of  helpful  comments  as  a  result 
of  attempting  to  use  the  document  in  creating  an  lA  model  for  wire¬ 
frame  geometry. 


However,  final  responsibility  for  any  errors  and/or  omissions  is  mine. 
Comments,  verbal  or  in  writing,  are  requested  and  should  be  directed 
to  me  at 

IBM  Dept  75E 
11601  Wilshire  Blvd. 

Los  Angeles,  CA  90025 

Telephone:  (213)  312-5975. 
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The  primitives  are  positions,  directions,  and  scalars.  The  geom¬ 
etry  is  limited  to  points  and  curves,  both  bou  .ied  and  unbounded. 

Vectors  are  defined  but  not  used,  as  we  found  it  more  natural  to  work 
with  the  direction  portion  in  constructing  the  conics. 

All  entities  may  be  named;  however  the  entity  name  is  always  op¬ 
tional.  The  symbolic  use  of  names  has  not  been  completely  worked  out 
yet.  For  this  document  the  type  'Pointer'  will  be  used  to  hide  some  of 
the  various  ways  entities  may  be  used  or  referred  to.  This  is  a  complex 
problem  that  is  not  fully  addressed  here.  The  examples  at  the  end  of 
this  section  and  the  section  on  grouping  mechanisms  provide  some  dis¬ 
cussion  of  this  issue. 


We  came  to  a  number  of  conclusions  about  the  geometry  and  how  it 
should  be  treated: 


We  attempted  to  pick  a  minimal  set  of  geometric  entities.  WTiere 
this  rule  has  been  violated,  I  have  explained  the  reasoning  behind 
our  choices . 

2D  and  3D  geometry  have  been  separated  explicitly.  This  saves 
space  for  2D  data  and  makes  it  explicit  when  data  is  planar. 

This  has  been  a  controversial  issue.  However,  I  think  that  we 
made  the  correct  choice.  There  are  systems  that  are  inherently 
2D:  drafting  coordinates,  parameter  space,  and  2D  viewing  coord¬ 
inates.  Offset  curves  need  to  be  2D.  The  IGES  A£C  committee 
did  a  surv'ey  of  vendors '  use  of  subfigures  which  indicated  that 
the  distinction  would  be  of  use. 

It  is  necessary  to  be  able  to  say  as  much  symbolically  as  is 
practical.  It  is  better  for  an  exchange  file  to  be  able  to 
state  that  two  curves  share  a  common  endpoint  or  that  two  com¬ 
posite  curves  share  a  segment  than  to  try  to  compute  this  sort 
of  information.  Since  we  are  attempting  to  build  a  standard 
that  will  be  able  to  grow  to  meet  future  needs,  these  sorts  of 
capabilities  need  to  be  built  into  the  standard  even  if  there 
is  no  great  need  for  them  at  present.  This  is  especially  true 
for  solid  modeling  considerations. 

A  generic  set  of  entities  should  be  used  for  geometry  so  as  to 
be  able  to  use  them  also  to  deal  with  topology  and  numeric 
control.  I  did  not  discuss  here  how  to  implement  these  other 
uses  (but  hope  to  deal  with  topology  no  later  than  3/86). 

We  need  ultimately  to  say  precisely  when  an  entity  is  well  de¬ 
fined.  Some  of  this  is  syntactic  and  some  semantic.  The  form¬ 
alisms  for  the  syntactic  aspects  are  well  known  and  understood; 
those  for  the  semantics  are  not.  The  geometric  tolerancing 
issues  discussed  here  are  the  beginnings  of  that  issue  as  seen 
by  the  computational  geometer. 

We  have  tried  to  choose  the  most  stable  representations  for  the 
commonly  used  CAD/CAM  geometric  entities.  By  stability  we  mean 
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that  a  small  change  in  the  data  for  the  entity,  due  perhaps  to 
truncation  in  its  ASCII  representation,  results  in  a  small 
change  in  the  pointset  defined  by  the  geometry.  The  case  of 
the  original  definition  of  the  IGES  conic  entity  is  a  good 
example  of  an  unstable  representation. 
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PART  1:  GEOMETRY 


The  Wireframe  geometric  entities  are  points  and  curve  segments . 
aid  in  their  definition  we  have  some  auxiliary  entity  types: 

Positions 

Directions 

Vectors 

Curves 

Transformation  matrices 


To 


Tolerancing  is  addressed  here  as  strictly  a  geometric  approximation 
issue. 


Position 


PositionZ  =  entity_type 

Name  :  optional  string; 
X  :  real; 

y  :  real; 

end; 

Position3  =  entitj'_type 

Name  ;  optional  string; 

X  :  real; 

Y  ;  real; 

Z  :  real; 

end; 


There  is  a  subtle  distinction  made  here  between  Positions  and  Points 
(defined  later).  Points  are  considered  to  be  CAD/CAM  entities  which 
are  to  be  translated  as  geometry;  Positions  are  constructs  used  in 
defining  geometry  (for  example,  control  points  for  a  B-spline).  In 
use  in  an  exchange  syntax,  one  would  want  to  allow  any  Pointer  to 
a  Position  to  be  satisfied  by  a  Pointer  to  a  Place. 

The  objection  to  homogeneous  coordinates  is  that  they  are  only 
used  for  control  points  for  splines  and  it  then  becomes  difficult 
to  symbolically  express  that  the  same  point  is  being  on  two  or 
more  curves  if  the  homogeneous  coordinate  is  different. 
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Direction 


Direct ion2  =  entity_type 

Name  :  optional  string; 

X  :  real; 

Y  :  real; 

end; 

Directions  =  entity_type 

Name  ;  optional  string; 

X  :  real; 

Y  :  real; 

Z  :  real; 

end; 

where 

(X’^^2  +  Y**2)**l/2  =  1  for  DirectionZ 

(XVf*2  +  Y’W'2  +  Z--">2)-'^n/2  =  1  for  Directions 

We  have  made  Position  and  Direction  the  lowest  level  of  what  can  be 
addressed  symbolically.  It  might  be  desirable,  and  it  would  be 
simple,  to  allow  addressing  the  component  scalars. 


Vector 


VectorZ  -  entity_type 

Name  :  optional  string; 

Direction  :  PositionZ; 
Magnitude  :  real; 
end; 

Vectors  =  entity_type 

Name  :  optional  string; 

Direction  :  Positions ; 
Magnitude  :  real ; 
end; 


This  representation  allows  for  least  error  in  cases  where  the 
vector  magnitude  is  small.  It  also  makes  it  easy  to  symbolically 
express  that  two  or  more  vectors  have  the  same  direction. 


Transformation  Matrix 


Trans_mtx2  =  exitity_type 

Name  :  optional  string; 

NewX  :  Pointer (Direction2) ; 

NewY  ;  Pointer(Direction2) ; 

KewO  ;  Pointer (Position2) ; 

end; 

Trans_mtx3  =  entity_type 

Name  :  optional  string; 

NewX  :  Pointer (Directions) ; 

NewY  :  Pointer (Directions) ; 

NewZ  ;  Pointer(DirectionS) ; 

NewO  :  Pointer (Positions) ; 

end; 


The  transformation  matrix  is  as  defined  in  IGES.  Most  systems 
probably  store  the  data  in  this  fashion.  The  rotation  portion  is 
viewed  as  orthonormal  vectors.  As  such,  they  must  meet  the  criteria 
for  being  perpendicular  and  unitary  established  under  the  heading  of 
Geometric  Tolerance. 

If  one  wishes  to  scale  in  any  direction,  this  can  be  done  separately 
(consistent  with  the  definition  and  use  of  vectors),  with  scale  factors 
for  the  different  directions. 

Transformation  matrices  may  be  applied  to  geometry,  instances  of 
geometry,  and  to  groupings  that  have  explicitly  been  labelled  as 
movable  (or  copy able)  in  space. 
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Curve 


A  curve  is  to  be  thought  of  as  a  parameterized,  continuous,  possibly 
unbounded  curve  in  space.  The  curve  entities  are: 

“  line 

-  circle 

-  ellipse 

-  parabola 

-  hyperbola 

-  spline 

-  compos i te  curve 

Note  that  the  last  three  of  these  have  bounded  parameter  spaces. 

The  choices  made  for  the  representations  of  the  conics  reflect: 

-  geometric  stability. 

-  one  of  the  many  conflicting  sets  of  design  intent. 

-  the  expectation  that  most  systems  already  have  available  pro¬ 
cedures  to  go  between  their  native  system  representations  and  the 
geometric  ones  used  here.  This  is  one  of  the  major  reasons  why 
the  B-spline  was  not  chosen  as  the  sole  representation  form  for 
curves . 

Curves  are  bounded  by  the  segment  entity  type.  A  Segment  consists 
essentially  of  a  Pointer  to  a  curve  (or  the  definition  of  the  curve 
embedded  within  the  segment!  plus  the  endpoints  of  the  segment. 


A  number  of  the  comments  suggest  that  the  first  draft  failed  to  des¬ 
cribe  our  intent  as  to  the  use  of  curves  and  segments  with  sufficient 
clarity.  We  had  intended  that  the  language  for  PDES  should  make  much  of 
this  transparent  to  systems  not  interested  in  the  flexibility  we  created 
We  do  not,  in  general,  expect  that  people  will  be  passing  lines,  conics, 
and  splines  as  they  do  now  in  IGES.  Rather,  they  will  be  passing  seg¬ 
ments  composed  of  these  entities.  We  have  tried  to  set  up  the  informa¬ 
tion  content  of  these  entities  so  that  the  PDES  syntax  could  deal  with 
them  in  a  straightforward  and  efficient  manner.  The  examples  given  to¬ 
wards  the  end  of  this  paper  should  be  of  some  help  in  understanding  this 
issue. 


Some  notation  has  been  set  up  to  describe  the  paramet.2rization  of 
the  conic  sections: 

Mtx(A,B,C)  is  the  rotation  matrix  created  by  using  3D  vectors  A,  B, 
and  C  as  the  columns  of  the  3X3  array.  If  A  and  B  are  2D,  the  third 
coordinate  of  the  corresponding  3D  vector  is  0.0. 

Tr(X)  is  the  transpose  of  the  vector  X. 

A  X  B  is  the  cross  product  of  vectors  A  and  B. 
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Line 


Line2  =  entity_type 

Name  :  optional  string; 

Pt2  :  Pointer(Position2) ; 

Vt2  :  Pointer(Direction2) ; 

Parra  :  optional  parameterization; 

end; 

Line3  =  entity__type 

Name  ;  optional  string; 

Pt3  :  Pointer(Position3) ; 

Vt3  :  Pointer (Directions) ; 

Parra  :  optional  parameterization; 

end; 


where 

Pt2  (Pt3)  is  a  point  on  the  line. 

Vt2  (Vt3)  is  the  direction  of  the  line. 

and  the  default  parameterization  is 
C(u)  =  Pt  Vt*u 


Two  lines  are  identical  as  point  sets  if  they  have  the  same  named 
Position  and  Direction  (i.e.,  the  referencing  is  symbolic).  When 
we  define  parameterization  techniques,  they  may  still  be  different 
lines  if  the  parameter izat ions  differ.  This  distinction  between 
point  sets  and  parameterized  curves  will  be  maintained  for  the  conics. 
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Circle 


Circle2  =  entity_type 

Name  :  optional  string; 

Center  :  Pointer (Position2) ; 

Radius  :  real; 

Sdir  :  optional  Pointer(Direction2) ; 

Parm  :  optional  parameterization; 

end ; 


Circles 


entity_type 

Name  :  optional  string; 

Axis  :  Pointer(Direction3) ; 

Center  :  Pointer (Positions) ; 

Radius  :  real; 

Sdir  :  optional  Pointer(DirectionS) ; 

Parm  :  optional  parameterization; 

end; 


where 

Axis  is  normal  to  the  definition  plane  of  the  circle 
(the  value  of  Axis  for  the  2D  case  is  (0,0,1)). 

Center  is  the  center  of  the  circle. 

Radius  is  the  radius  of  the  circle 

Sdir  points  from  the  center  to  the  start  point  of  the  circle. 

and  the  default  parameterization  is 
C(u)  =  Center 

Radius*Mtx(Sdir ,Axis  X  Sdir , Axis )*Tr (cos  u,sin  u,0.0) 


r 


Ellipse 


Ellipse2 


Ellipses 


=  entity_type 


Name 

:  optional  string; 

Center 

:  Fointer(Position2) ; 

Mjdir 

:  Pointer (Direction2) ; 

Axmj 

:  real; 

Axmn 

;  real ; 

Farm 

:  optional  parameterization; 

end; 

entity_ 

type 

Name 

:  optional  string; 

Axis 

:  Pointer (Directions) ; 

Center 

:  Pointer(Position3) ; 

Mjdir 

:  Pointer (Directions) ; 

Axmj 

:  real; 

Axmn 

:  real; 

Farm 

:  optional  parameterization; 

end; 

where 

Axis  is  the  normal  to  the  definition  plane  of  the  ellipse 
(the  value  of  Axis  for  the  2D  case  is  (0,0,1)). 

Center  is  the  center  of  the  ellipse. 

Mjdir  is  the  direction  of  the  major  axis  of  the  ellipse. 

Axmj  is  the  magnitude  of  the  major  semi^axis. 

Axmn  is  the  magnitude* of  the  minor  semi*axis. 

and  the  default  parameterization  is 
C(u)  =  Center 

+  Mtx(Mjdir .Axis  X  Mjdir .Axis )*Tr(Axmj*cos  u,Axinn*sin  u,0.0) 


Parabola 


Parabola2  =  entity_type 

Name  :  optional  string; 

Vtxpt  :  Pointer fPos it ion2 ) ; 

Faxis  :  Pointer(Direction2) ; 

Fdist  :  real; 

Farm  :  optional  parameterization; 

end; 

Parabolas  =  entity_type 

Name  :  optional  string; 

Axis  :  Pointer (Directions ) ; 

Vtxpt  :  Pointer (Pos itionS) ; 

Faxis  :  Pointer(DirectionS) ; 

Fdist  :  real; 

Farm  :  optional  parameterization; 

end ; 

where 

Axis  is  the  normal  to  the  definition  plane  of  the  parabola 

(the  value  of  Axis  for  the  2D  case  is  (0,0,1)). 

Vtxpt  is  the  vertex  of  the  parabola. 

Faxis  is  the  direction  of  the  axis  of  the  parabola. 

Fdist  is  the  focal  distance  of  the  parabola. 

and  the  default  parameterization  is  , 

C(u)  =  Vtxpt 

+  .Mtx (Faxis  , Axis  X  Faxis , Axis )*Tr (u*^2/ (4*Fdist )  ,u, 0.0) 
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Hyperbola 


Hyperbola2  =  entity_type 

Name  :  optional  string; 

Center  ;  Pointer(Position2) ; 

Mjdir  :  Pointer (Direct ion2 ) ; 

Axm j  ;  rea  1 ; 

Axmn  :  real; 

Parm  :  optional  parameterization; 

end; 

Hyperbolas  =  entity_type 

Name  :  optional  string; 

Axis  :  Pointer(Direction3) ; 

Center  :  Pointer(Position3) ; 

Mjdir  :  Pointer (Directions) ; 

Axmj  :  real; 

Axmn  :  real; 

Parm  :  optional  parameterization; 

end; 


where 

Axis  is  the  normal  to  the  definition  plane  of  the  hyperbola 
(the  value  of  Axis  for  the  2D  case  is  (0,0,1)), 

Center  is  the  center  of  the  hyperbola. 

Mjdir  is  the  direction  of  the  major  axis  of  the  hyperbola. 

UTien  positioned  at  Center,  it  points  to  the  chosen  branch 
of  the  hyperbola. 

Axmj  is  is  the  scalar  magnitude  of  the  major  semi-axis  of  the 
hyperbola. 

Axmn  is  is  the  scalar  magnitude  of  the  minor  semi-axis  of  the 
hyperbola. 

and  the  default  parameterization  is 

C(u)  =  Center 

+  Mtx(Mjdir .Axis  X  Mjdir ,Axis)*Tr(Axmj*sec  u,Axmn*tan  u,0.0) 


where  -PI/2  <  u  <  PI/2. 


Spline 


Spline 


entity_type 

Name 

Dim 

Order 

Ctlpts 

Weights 

Knts 


end; 


optional  string; 
integer  value(2..3); 
integer  value(2. .maxint) ; 
array (0..K)  of  Pointe r( Posit ion ) ; 
optional  array(0..K)  of  real; 
case  of 

array( - (Order-1) .. (K+1))  of  real; 
array(-(Order-l) . . (K+1) )  of  integer; 


where 


Dim 

is 

Order 

is 

Weights 

is 

is 

Ctlpts 

is 

or 

Knts 

is 

or 

K 

is 

It 

maxint 


It  is  either  an  array  of  real  numbers 


represents  the  largest  integer  the  computer  can  represent. 
This  is  merely  a  notational  convenience  for  saying  that  the 
order  must  be  at  least  2  -  i.e.,  the  spline  must  be  at  least 
linear  -  but  otherwise  of  arbitrary  order. 


The  E -spline  was  chosen  as  it: 

-  provides  a  stable  representation  form; 

-  it  completely  describes  the  class  of  polynomial  splines; 

-  is  used  by  a  large  (and  increasingly  so)  percentage  of  CAD/CAM 
systems  as  their  representation  scheme  for  curves. 

The  spline  has  been  limited  to  being  2  or  3  dimensional.  For  NC  and 
other  use  in  the  future  it  may  be  desirable  to  relax  this  restriction. 
This  why  we  did  not  create  types  spline2  and  spline3. 

Further  clarifying  details  of  computation  of  B-splines  may  be  found 
in  the  IGES  documents.  The  spline  information  used  here  and  the  nota¬ 
tion,  except  for  the  uniform  spacing  case,  is  as  found  in  the  IGES  126 
entity. 
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It  is  desirable  that  the  syntax  of  the  file  structure  be  able  to  ex¬ 
press  repeated  knots  and  control  points  in  some  compact  manner.  One 
way  of  doing  this  would  be  for  the  default  values  in  sequences  of  tuples 
to  be  the  coordinate  of  the  previous  tuple. 

Examples : 

(1)  in  a  knot  sequence, 

2. . 3 

would  be  the  same  as 
% 

(2)  in  a  sequence  of  ordered  pairs 

2.3. . .6.7 

would  be  the  same  as 

2, 3, 2, 3, 6, 7 

if  the  sequence  were  really  (2,3) , (2,3) , (6,7) 

(3)  in  a  sequence  of  ordered  pairs 

2.3. . 5.6.7 

would  be  the  same  as 
•j  3  *>  5  6  7 

if  the  sequence  were  really  (2 ,3) , (2 ,5) , (6 , 7) 
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Composite  Curve 


comp_constituent_entity2  =  record 

Constituent  :  Pointer (Segment2) ; 

Sense  :  oprional  boolean; 

Cntseg  :  optional  integer  values(0..2) 

end; 

comp_constituent_entit:y3  =  record 

Constituent  :  Pointer (Segments) ; 

Sense  :  optional  boolean; 

Cntseg  :  optional  integer  values (0.. 2) 

end; 


CCurve2  =  entity_type 

Name  :  optional  string; 

Cntflg  ;  optional  Integer  Values(0. .2) ; 

Closeflg  :  optional  Boolean; 

Seglist  :  list  of  comp_constituent_entity2; 

end; 

CCurveS  =  entity_type 

Name  ;  optional  string; 

Cntflg  ;  optional  Integer  Values(0. .2) ; 

Closeflg  :  optional  Boolean; 

Seglist  :  list  of  comp_^constituent_entity3 ; 

end; 


where 

Sense  is  'T*  (default)  if  the  underlying  curve  segment  has  the  same 
sense  as  the  composite  curve.  Otherwise,  sense  is  'F'. 

Cntflg  indicates  whether  the  curve  is: 

0  -  continuous  (CO  is  required) 

1  -  has  continuous  tangent  direction 

2  -  has  continuous  curvature  direction 

Cntseg  indicates  the  same  for  the  point  common  between  this  segment 
and  the  next. 

Closeflg  is  ’F’  (default)  if  the  curve  is  open,  'T'  if  closed. 
Seglist  is  an  arbitrarily  large  list  of  constituent  entities. 

The  constituent  curves  must  have  the  correct  directionality.  That  is, 
the  end  point  of  one  is  the  start  point  of  the  next.  This  is  some¬ 
thing  that  can  be  said  symbolically  by  having  the  end  of  one  curve 
and  the  start  of  the  next  pointed  to  by  name.  It  can  also  be  tested 
for  by  determining  the  points  are  within  a  tolerance  to  one  another. 
The  former  method  is  the  preferred  one. 

They  must  also  have  the  same  dimensionality.  The  composite  curve  is 
either  2D  or  3D  so  all  of  the  constituent  elements  must  be  2D  or  they 
must  all  be  3D. 


There  has  been  a  request  that  the  CO  requirement  be  dropped.  This 
would  impose  no  great  hardship  on  PDES  processors  or  the  specification. 
We  would  need  to  spell  out  in  the  standard  when  this  was  required.  E.g., 
loops  in  topology  would  need  to  be  CO. 


The  parameterization  of  the  composite  curve  is  the  inherited  parameter- 
izations  of  the  constituent  curve  segments. 

That  is,  if  we  let 

C  be  the  composite  curve; 

N  be  the  number  of  constituent  curves; 

CC(i)  be  the  i-th  constituent  curve  (1  <=  i  <=  N) ; 

PS(i)  be  the  parametric  value  of  the  start  of  CC(i); 

PE(i)  be  the  parametric  value  of  the  end  of  CC(i); 

T(i)  be  the  sum  from  j=l  to  j=i  of  (PE(j)  -  PS(j)), 

where  T(0)  =  0.0.  (T(i)  is  the  accumulated  parametric 

length  up  to  the  end  of  the  i-th  constituent). 


Then 

(1)  the  parametric  values  of  C  range  from  T(0)  to  T(N); 

(2)  for  0  <=  u  <=  T(N), 

C(u)  =  CC(i)(u  -  T(i-l)  +  PS(i)) 

where  i  is  such  that  T(i-l)  <=  u  <=  T(i). 
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Point 


Point2 


Points 


entity_type 

Name  :  optional  string 
Position  :  PositionZ; 
end; 

entity_type 

Name  :  optional  string 
Position  :  Position2; 
end; 


Curve  Segment 


Segment2  =  entity_type 

Name  :  optional  string; 

Crv  :  optional  Pointer (CurveZ) ; 

Stpt  :  PositionZ; 

Endpt  :  PositionZ; 

Pst  :  optional  real; 

Pend  :  optional  real; 


end; 


Segments  =  entity_type 


Name 

:  optional  string; 

Crv 

:  optional  Pointer(Curve3) ; 

Stpt 

:  Positions; 

Endpt 

:  Positions; 

Pst 

:  optional  real; 

Pend 

:  optional  real; 

Path 

:  optional  boolean; 

end; 

where 

Crv  is  the  curve  that  is  bounded  by  the  endpoints . 

Crv  is  optional  as  the  default  is  a  line  segment, 
whose  definition  is  in  terms  of  its  endpoints. 

Stpt  is  the  start  point  on  the  curve. 

Endpt  is  the  end  point  on  the  curve. 

Pst  is  the  parametric  start  point  of  the  curve. 

Pend  is  the  parametric  end  point  of  the  curve. 

Path  is  'T'  if  the  segment  is  counterclockwise  as  seen  from  the 

Axis  direction  (the  value  of  Axis  for  the  20  case  is 
(0,0,1)).  Otherwise  it  is  ’F’.  The  default  is  'T' . 
This  is  only  needed  for  the  closed  curves  (circle, 
ellipse,  and  closed  composite  curve)  when  there  is 
ambiguity  as  to  the  path  the  segment  is  on. 


The  endpoints  are  the  primary  means  of  trimming  segments.  This  makes 
explicit  when  continuity  is  desired.  Parametric  values  were  specified 
as  being  optional  and  were  intended  to  be  used  only  in  those  cases 
where  the  curve  was  self-intersecting. 

Pst  and  Pend  must  be  used  if  the  curve  has  more  than  one  parametric 
value  for  either  the  start  or  end  point.  That  is,  if  there  are  tO 
and  tl  such  that 

Stpt  =  crv(tO)  =*crv(tl)  or  Endpt  =  crv(tO)  =  crv(tl) 
Otherwise,  they  need  not  be  used. 

The  direction  of  the  curve  segment  is  from  the  Stpt  to  Endpt. 


-20 


It  is  desirable  that  the  syntax  of  the  file  structure  be  able  to  ex¬ 
press  curve  segments  which  are  defined  in  terms  of  already  bounded 
curves  (e.g.,  full  circles  and  ellipses,  splines,  composite  curves) 
and  in  have  the  same  endpoints  in  some  compact  manner. 
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Geometric  Tolerances 


There  seem  to  be  two  distinct  sorts  of  tolerances: 


T_V  to  indicate  that  two  vectors  are  perpendicular  or  parallel, 

T_P  to  indicate  that  two  points  are  identical  or  that  a  point 
is  on  a  curve. 


T  V  can  be  used  as  follows: 


VI 

is  parallel  to  V2 

iff 

(1-T_V) 

<  abs(Vl  dot 

V2) 

<  (1+T_V) 

VI 

is  perpendicular  to  V2 

iff 

0 

<=  abs(Vl  dot 

<  +  T_V 

VI 

has  magnitude  1 

iff 

(1-T_V) 

<  abs(Vl  dot 

VI) 

<  (1+T_V) 

T_P  can  be  used  as  follows: 

PI  =  P2  iff  dist(Pl,P2)  <  T_P 

PI  is  on  Cl  iff  dist(Pl,Cl)  <  T_P 

where  PI  and  P2  are  points  and  Cl  is  a  curve. 


Also,  for  open  bounded  curves  one  can  require  that 
dist (Start_pt ,End_pt)  >  T_P 
and  for  closed  bounded  curves  cne  can  require  tha- 
dist(Start_pt,End_pt)  <  T_P 


Of  course,  computationally  one  would  probably  wish  to  use  t_P’-*2 
and  dist'^-'-2. 


Discussions  in  the  IGES  Curves  and  Surfaces  Committee  suggest  that 
the  sending  system  should  document  its  criteria  for  establishing  tol¬ 
erances.  The  receiving  system  should  document  its  criteria  for  accept¬ 
ing  data  and  its  fixups,  if  any,  and  it  should  output  some  sort  of  mes¬ 
sage  for  any  entities  that  are  either  altered  or  rejected. 
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Examples : 


A  line  segment  in  the  WF  proposal  is  a  line  with  endpoints.  There  is 
no  reason  why  the  line  couldn't  be  defaulted  to  the  nil  name  so  that  the 
result  is  a  line  segment  defined  by  two  points.  Similarly,  with  the 
closed  conics  (circle  and  ellipse)  the  file  structure  might  well  be  set 
up  so  that  null  endpoints  indicate  that  the  segment  is  a  full  circle  or 
ellipse.  Segments  composed  of  splines  and  composite  curves  that  are  not 
trimmed  could  use  the  same  mechanism. 

The  following  would  all  define  the  same  line  segment.  It  illustrates 
the  systematic  approach  of  being  able  to  use  either  data  or  pointers  to 
data.  This  is  a  generalization  of  the  approach  taken  by  PDDI.  In  fact, 
the  second  and  third  cases  fit  that  defining  methodology. 

There  is  a  more  subtle  issue  of  the  need  to  be  able  to  reference  the 
same  geometry  in  different  ways  that  is  covered  later  in  the  discussion 
of  the  grouping  mechanism. 

The  notation  used  is  only  menat  to  be  suggestive.  One  would  expect 
the  actual  physical  representation  to  be  far  more  compact. 

(1)  LSA  =  Segment2 

seg_type  =  Line2 
Position2CXl ,Y1) 

Position2(X2,Y2) 

seg2_def_end 

(2)  LSA  =  Segraent2 

seg  type  =  Line2 
PTr=  Position2(Xl,Yl) 

PT2  =  Position2(X2,Y2) 
seg2_def_end 

(3)  PTl  =  Position2(Xl,Yl) 

PT2  =  Position2(X2,Y2) 

LSA  =  Segment2 

seg  type  =  Line2 
PTl' 

PT2 

seg2_def_end 

(4)  PTl  =  Position2(Xl,yi) 

PT2  =  Position2(X2,Y2) 

LSA  =  Segment2 

seg  type  =  Line2 
Linc2((XS,YS),(V’X,VY)) 

PTl 

PT2 

seg2_def_end 


-23- 


(5)  PTl 
PT2 
Li 
LSA 


(6)  PTl 
PT2 
PTS 
VT 
LI 
LSA 


Position2 (XI ,Y1) 

Pos it ion2 (X2 , Y  2 ) 

Line2((XS,YS).(VX.VY)) 

Segnient2 

seg_type  =  Line2 

Li 

PTl 

PT2 

seg2_def_end 

Position2(Xl,Yl) 

Position2CX2,Y2) 

Position2(XS.YS) 

Direction2(VX,Vy) 

Line2(PTS,\T) 

Segment2 

seg  type  =  Line2 
LI  ' 

PTl 

PT2 

seg2_def_end 


Cases  (4)  to  (6)  are  subject  to  the  constraint  that  PTl  and  PT2 
must  be  within  some  tolerance  of  the  line  defined  by  the  point 
(XS.YS)  and  the  vector  (\TC,VY). 


-24- 


PART  2:  ASSOCIATED  ENTITES 


These  consist  of 


Definition  and  Instance  entities 
Group 

External  Referencing 


r 

c 
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Internal/extemal  instancing 


Instancing  is  the  use  of  entities  (or  structures  of  entities) 
defined  as  quasiprimitives,  perhaps  with  arguments.  The  term  quasi¬ 
primitive  is  deliberately  left  undefined,  but  it  is  intended  here  to 
refer  to  geometry  that  is  use  as  a  primitive  definition  by  the  CAD 
system.  Many  systems  use  this  technique,  along  with  libraries  to 
contain  definitions  for  use  throughout  the  installation. 

definition_entity  =  entity_type 

Name  :  string; 

Dim  :  optional  integer; 

constituent_list  :  list  of  Pointer (Geometry) 

end; 

where 

Name  is  the  required  name  of  the  definition  to  be  referenced  when 
used. 

Dim  is  the  dimensionality  of  the  definition.  We  are  currently 
restricting  it  to  2  or  3.  The  default  is  3. 

Pointer (Geometry)  means  that  the  entities  in  the  list  must  be 

geometric  entities  or  named  instances  of  them.  Nesting  of 
instances  of  other  definitions  within  a  definition  is  allowed 
provided  there  is  no  self -referencing. 

instance_entity  =  entity_type 

Name  :  optional  string; 

Def_name  :  string; 

trans  :  Pointer(trans_mtx) ; 

def_ref  :  Pointer(definition_entity) ; 

scale  :  optional  case  of 

array(1..3)  of  real; 
optional  real; 

end; 

where 

Def_name  is  the  name  of  the  definition  being  instanced, 
trans  is  a  transformation  matrix  used  to  position  the  instance. 
def_ref  is  the  name  of  the  definition  being  used, 
scale  is  an  optional  scale  factor  for  the  X,  Y,  and  Z  directions 

respectively  of  the  definition  entity  before  it  is 
positioned  by  the  transformation  matrix.  If  only  one 
value  is  used  (probably  the  most  commonly  used  mechanism), 
it  applies  to  all  three  directions. 

There  has  been  a  request  to  put  a  nesting  level  into  the  definition. 

We  did  not  do  so  because  a  strict  def ine-before-use  semantics  would  make 
this  unnecessary. 
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Grouping  Mechanism 


group_entity  =  entity_type 
Name 

Movable_f lag 
trans 

consti'Cuent_list 

end; 


optional  string; 
optional  boolean; 
optional  Pointer (trans_mtx) ; 
list  of  Pointer(Geometry) ; 


where 

.iOvable_f lag  indicates  whether  the  group  is  to  be  considered  as  a 

physical  thing  that  can  be  moved  in  space.  The  default 
is  'F'. 

trans  is  a  transformation  matrix  used  to  position  the  group. 

It  may  only  be  used  if  the  Movable_f lag  is  set  to  'T' . 


The  movable_flag  is  optional  and  its  presence  indicates  that  the 
geometry  defined  or  instanced  in  the  group  is  to  be  moved  by  any 
transformation  matrix  applied  to  the  group.  Note  that  in  case  (2) 
below  the  geometry  has  been  defined  elsewhere. 

No  doubt  there  will  be  other  attributes  one  might  wish  to  add  to 
the  grouping  mechanism,  but  this  seems  sufficient  for  a  start. 
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The  issue  of  the  kinds  of  addressing  that  may  be  done  is  complex 
and  has  not  really  been  resolved  within  IGES.  Here  is  a  discussion 
of  some  of  the  kinds  of  addressing  that  need  to  be  done. 

The  elements  in  the  list  may  be; 

(1)  defined  within  the  scope  of  the  list, 
ex: 

begin  group 

begin  point  (optionally  named) 


end  point 


end  group 

(2)  referenced  by  name  from  outside  the  group. 

The  geometry  already  exists  within  the  model. 
e.x; 

begin  group 

ref  PT_A 


end  group 

(3)  an  instance  of  a  definition  made  from  outside  the  group, 
ex: 

begin  group 

inst  PT_A 


end  group 

(4)  an  instance  of  geometry  defined  elsewhere  that  already  exists 
in  the  model  and  is  not  a  definition. 

One  example  is  the  same  as  (3)  above.  A  more  illustrative 
example  is  the  following: 

Consider  two  ruled  surfaces; 

RSI  is  defined  by  segments  Sa  and  Sb. 

Sa  and  Sb  are  defined  inside  the  scope  of  RSI. 

RS2  is  defined  by  segments  Sb  and  Sc. 

Sc  is  defined  inside  the  scope  of  RS2. 

Suppose  one  wishes  to  apply  a  transformation  matrix  to  RSI. 
There  are  two  choices  as  to  what  can  happen  to  RS2.  It  can 
change,  being  dragged  along  by  RSI,  or  it  can  remain  the  same, 
being  uncoupled  from  RSI.  In  the  latter  case,  one  might  well 
wish  to  continue  to  say  symbolically  the  following; 
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if  the  two  surfaces  were  joined  together,  they  would  be 
CO  continuous. 


If  a  reference  to  Sb  were  used,  the  first  meaning  would  be 
used;  if  an  instance  of  Sb  were  used,  the  second  would. 


Another  way  to  look  at  this  is  to  go  back  to  the  example  in  which 
a  line  segment  was  defined  in  6  different  ways.  Assume  for  this  dis¬ 
cussion  that  the  segment  has  a  transformation  matrix  associated  with 
it.  Then  in  cases  (3)  to  (6)  one  needs  to  be  able  to  specify  that 
the  transformation  matrix  is  (inst  case)  or  is  not  (ref  case)  applied 
to  the  position  of  the  point  or  line  that  has  been  defined  outside  of 
the  scope  of  the  segment.  The  language  must  be  able  to  express  both  of 
these  cases. 
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External  Referencing 


Xref  =  entity_type 

Entity_name  :  string; 

Entity_class  ;  entity_type; 

File  :  optional  string; 

end; 

Xreftab  =  entity_type 

Table_name  :  optional  string; 
Refs  :  list  of  Xref_type; 

end; 


where 

Entity_name  is  the  name  of  the  entity  in  its  defining  file. 
Entity_class  is  from  (Curve2,  Curves,  Segments,  Segments, 
Definition_entity,  Group). 

File  is  the  name  of  the  PDES  file  in  which  the  entity 

is  defined. 

Table_name  is  the  name  of  the  cable  of  external  references. 
Refs  is  a  list  of  external  references. 


Use  of  external  referencing  is  dependant  upon  the  general  organization 
of  the  PDES  file  structure,  so  further  details  will  not  be  given  here. 


-SO- 


Appendix  Cl. 2 
Task  1 


(RESOURCE) 


p/Z0crios 


f  p:»i/s 


\ 


S/te.cf 


7^/f a;  J"  /I  r/^A/ 


to  ti 


Pv 


/z- 
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Appendix  Cl. 3 
Task  1 


frame  Geometry  Model  ( 


(RESOURCE) 
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PDES  SCHEMA 


TYPE 

t_continui ty 
—  used  to 


=  ENUMERATION  OF  <cO, 
indicate  continuity 


cl,  c2) 
state  at 


curve 


junctions. 


t_closure  =  ENUMERATION  OF  (open,  closed,  intersecting); 
—  used  to  indicate  the  closure  state  o-f  a  curve. 


t_cart_coord  =  REAL; 

—  used  -for  position,  direction  attributes, 
t .magnitude  =  REAL  >  0.0; 

—  used  whereever  a  positive  (non-zero)  real  is  required. 

—  the  syntax  for  qualifying  values  is  still  up  in  the  air. 

—  I  am  looking  at  Chai-Hui  Shih's  work  which  covers  this 

—  kind  of  thing  quite  completely. 

t_bit  *  LOGICAL; 

t_pro jecti on_type_code  =  ENUMERATION  OF (perspect i ve ,  parallel) 

t_cl ip. indicator  =  ENUMERATION  0F(clip,  noclip); 

t_paral lelogram  =  STRUCTURE; 

width  ;  REAL; 
length  :  REAL; 

END; 
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PDES  SCHEMA 


—  START  OF  WIRE  FRAME  GEOMETRY  ENTITIES 
VERSION  0.4 

—  AUTHOR  CLAPP 

CLASS  wire-frame  OF 

(wire-frame_geometry ,  wire-f rame_au>!i  1  iary)  ; 


CLASS  wire-f rame_gBometry  OF 
(point,  wi re-f rame_segment )  ; 

CLASS  point  OF 

(point2,  point3); 

CLASS  wi  re-f  rame_segment  OF 

(single_segment ,  composi te_segment ) ; 

CLASS  si ngl e_segment  OF 

(curve_segment2 ,  curve_segment3) ; 


CLASS  composi te_segment  OF 

(composi te_curve2 ,  composi te_curve3> ; 


CLASS  wi  re-f  rame_au,'<  i  1  i  ary  OF 

(au«  i  1  i  ary_curve ,  position,  vector,  trans-f  ormation_matri  x  ) 


CLASS  aux i 1 i ary_curve  OF 
(curve2,  curvB3,  spline); 

CLASS  curve2  OF 

(ellipse2,  parabola2,  hyperbolae,  line2,  circle2>; 


CLASS  curve3  OF 

(ellipse3,  parabola3,  hyperbolas,  line3,  circleS); 


CLASS  position  OF 

(position2,  positions); 


CLASS  vector  OF 

(non_uni t _vector ,  direction); 


PDES  SCHEMA 


CLASS  non_uni t^vector  OF 
(vector2,  vector3) ; 


LASS  direction  OF 
(direction2,  direction3); 


CLASS  trans-format ion_(natrij<  OF 
(trans_matr i liZ ,  trans_matr i>:3)  ; 


ENTITY  place2; 

NOROLE 

name  :  OPTIONAL  string; 
ROLE 

X  :  t_cart_coord ; 
y  :  t_cart_coord; 

END; 


ENTITY  place3; 

NOROLE 

name  ;  OPTIONAL  STRING; 
ROLE 

:  t_cart_coord ; 
y  :  t_cart_coord; 
z  :  t_cart_coord; 


ENTITY  point2; 

NOROLE 

name  :  OPTIONAL  STRING; 

ROLE 

location  ;  REFER (  place2  ); 
END; 


ENTITY  points; 

NOROLE 

name  :  OPTIONAL  STRING; 
ROLE 

location  :  REFER (  place3 
END; 
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PDES  SCHEMA 


ENTITY  vector 2; 

NOROLE 

name  :  OPTIONAL  STRING; 


ROLE 
i  : 
j  ! 
1  : 
END; 


t_cdrt_coord 
t_cart_coord 
t_magni tude; 


ENTITY  vector 3; 

NOROLE 

name  :  OPTIONAL  STRING; 
ROLE 

i  :  t_cart_coord; 
j  :  t_cart_coord; 
k  :  t_cart_coord; 

1  :  t_magnitude; 

END; 


ENTITY  directionC; 

NOROLE 

name  s  OPTIONAL  STRING; 
ROLE 

i  :  t_cart_coord; 
j  ;  t_cart_coord ; 

END; 


ENTITY  direction3; 

NOROLE 

name  :  OPTIONAL  STRING; 
ROLE 

X  :  t_cart_coord; 
j  :  t_cart_coord ; 
k  :  t  cart_coord; 

END; 


ENTITY  line2; 

NOROLE 

name  i  OPTIONAL  STRING; 

ROLE 

place  :  REFER (  place2  ); 
direction  i  REFER (  di recti on2 
END; 
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PDES  SCHEMA 


ENTITY  line3; 
NOROLE 


name 

IDLE 


OPTIONAL  STRING; 


place  :  REFER (  place3  ); 
direction  :  REFER (  directions 


END; 


); 


ENTITY  circle2; 

NOROLE 

name  :  OPTIONAL  STRING; 

ROLE 

center  ;  REFER (  place2  ); 
radius  :  t_magnitude; 
start  :  REFER (  directions  ); 
END; 


ENTITY  circles; 

NOROLE 

name  :  OPTIONAL  STRING; 
ROLE 


ax  i  s  : 


center 

radius 

start 

ND; 


REFER (  directions  ); 

;  REFER <  placeS  ); 

:  t^magnitude; 

REFER (  directions  ); 


ENTITY  ellipse2; 

NOROLE 

name  :  OPTIONAL  STRING; 

ROLE 

center  i  REFERS  place2  ); 
majoraxis  ;  REFER <  direction2  ); 
semimajor  :  t_magnitude; 
semi  mi  nor  :  t_magnitude; 

END; 


ENTITY  ellipses; 

NOROLE 

name  :  OPTIONAL  STRING;’ 

ROLE 

center  :  REFER (  places  >; 
majoraxis  :  REFER (  directions  ); 
semimajor  :  t.magnitude; 
semi  mi  nor  :  t_magnitude; 
normal  ax  is  :  REFER (  directions  ); 
END; 


PDES  SCHEMA 


ENTITY  parabolae; 

NOROLE 

name  ;  OPTIONAL  STRING; 

OLE 

vertex  t  REFER (  place2  ); 
axis  :  REFER<  direction2  ); 
■focaldist  :  t_magnitude; 
END; 


ENTITY  parabola3; 

NOROLE 

name  :  OPTIONAL  STRING; 

ROLE 

vertex  :  REFER (  place?  ); 
axis  ;  REFER  (  direction?;  ); 
■focaldist  :  t.magnitude; 
normalaxis  :  REFER (  directions  ); 
END; 


ENTITY  hyperbolae; 

NOROLE 

name  :  OPTIONAL  STRING; 

ROLE 

center  :  REFER (  place2  ); 
majoraxis  :  REFER(  direction2  ); 
semi  major  :  t_magnitude; 
semiminor  :  t_magnitude; 

END; 


ENTITY  hyperbola?; 

NOROLE 

name  ;  OPTIONAL  STRING; 

ROLE 

center  :  REFER (  place?  ); 
majoraxis  :  REFER (  direction?  ); 
semi  major  :  t^magnitude; 
semi  mi  nor  ;  t_magni  tude'; 
normalaxis  :  REFER (  direction?  ); 
END; 
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t^uts  SCHEMA 


ENTITY  spline; 
NOROLE 


name  ;  OPTIONAL  STRING; 


ROLE 

order  :  INTEGER  WHERE  RANGE  2  TO  MAXINT; 
dimension  ;  INTEGER  WHERE  RANGE  2  TO  3; 
uni-form  :  LOGICAL; 


control  point  :  ARRAY (0:*)  OF  REFER f  position  ); 

weight  :  OPTIONAL  ARRAY (O: UBOUND (control point ) )  OF  REAL; 

knotsequence  :  ARRAY  (- (order-1 );  <UBOUND(controlpoint )  •♦■1 )  ) 


NUMBER; 


OF 


END; 

—  NOTE:  UBOUND  is  a  built-in  -function  which  returns  an  integer 

—  number  which  is  the  upper  bound  o-f  an  array. 


ENTITY  curve_segment2; 

NOROLE 

name  :  OPTIONAL  STRING; 

ROLE 

base  :  REFER (  curve2d  ) ; 

path  :  LOGICAL; 

startpoint  .*  REFER  (  place2  ); 

endpoint  :  REFER (  pldce2  ); 

pstart  :  REAL; 

pend  :  REAL; 

END; 


ENTITY 
OROLE 
name 
ROLE 


curve_segment3; 

;  OPTIONAL  STRING; 


base  :  REFER (  curve3d  ); 
path  :  LOGICAL; 
startpoint  ;  REFER (  place3 
endpoint  :  REFER <  place3  ); 
pstart  :  REAL; 
pend  :  REAL; 

END; 


ENTITY  composi te_curve2; 

NOROLE 

name  ;  OPTIONAL  STRING; 

ROLE 

closure  ;  t_closure; 
degree  ;  t_continui ty; 
constituent  :  LIST  (2  TO  •*)  OF 
STRUCTURE; 

element  ;  REFER (  curve_segment2  ); 
sense  :  LOGICAL; 
degree  :  t_cont i nui ty ; 

END; 


PDES  SCHEMA 


ENTITY  composi te_curve3,; 

NOROLE 

name  ;  OPTIONAL  STRING; 

ROLE 

closure  :  t_closure; 
degree  .!  t_cont i  nui  ty ; 
constituent  :  LIST (2  TO  *)  OF 
STRUCTURE; 

element  :  REFER (  curve_segment3  >; 
sense  :  LOGICAL; 
degree  :  t_continui ty; 

END; 

END; 


ENTITY  trans_matri m2; 

NOROLE 

name  ;  OPTIONAL  STRING; 

ROLE 

irow  :  REFER (  direction2  ); 
jrow  ;  REFER (  direction2  ); 
translation  :  REFER <  place2  ); 
END; 


ENTITY  trans  matriM3; 

NOROLE 

name  :  OPTIONAL  STRING; 

ROLE 

irow  :  REFER (  di recti on3  ); 
jrow  ;  REFER (  dlrection3  ); 
krow  :  REFER <  direction3  ); 
translation  :  REFER (  place3  ); 
END; 
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Appendix  C2 
Task  1 
(RESOURCE) 


C2.1 

C2.2 

C2.3 


Presenfea-tion  Resource  Model 

Initial  Model  and  Documentation 
NIAH  Model 
DSL  Model 
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Appendix  C2.1 
Tas]c  1 


Presentation  Initial  Model  and  Documentatioi 


(RESOtJRCE) 
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Issues  •>  Presentation  Entities  for  PDES 


Richard  C.  Winfrey 
Consulting  Engineer 
cm  Technology 

Digital  Equipment  Corporation 
SHR1-3/E10 

Shrewsbury,  Massachusetts  01545-4112 
(617)  841-2192 

November  4,  1985 


Introduction 

The  following  is  a  list  of  comments  by  reviewers  of  the  DRAFT 
proposal  dated  June  14,  1985.  I  would  like  to  thank  them  for 
their  time  in  reviewing  the  document  and  for  their  perceptive 
comments.  Following  many  of  the  comments,  I  have  tried  to  offer 
an  answer,  or  add  further  explanation,  and  these  are  marked  as 
"RCW  response:".  These  are  strictly  my  personal  comments  and 
are  not  necessarily  those  of  the  PDES/IGES  committee. 

The  purpose  of  the  DRAFT  proposal  was  to  specify  the 
presentation  needs  of  PDES.  Once  those  needs  had  been  defined, 
with  the  help  of  the  PHIGS,  GKS-3D,  and  CG-VDI  proposals,  the 
result  was  very  nearly  that  of  PHIGS.  Therefore,  rather  than 
spend  additional  time  (redundant)  refining  the  DRAFT  proposal, 
the  following  recommendations  are  made: 

o  Identify  the  few  additional  needs  of  PDES  that  are  not 
included  in  PHIGS,  and  offer  them  to  the  PHIGS  committee  for 
inclusion  in  their  standard. 

o  With  the  help  of  the  PHIGS  committee,  define  a  PDES  level  of 
implementation.  The  entire  scope  of  the  PHIGS  functionality 
is  not  needed  for  PDES. 

o  Create  a  new  document  having  a  title  something  like:  "PDES 

Implementor's  Guide  to  the  use  of  PHIGS".  This  would  answer 
many  of  the  questions  that  have  been  raised  by  the  PDES/IGES 
committee  members  as  well  as  provide  a  convenient  place  to 
keep  examples  and  recommended  practices  that  relate  to 
graphics.  Typical  questions  might  be;  "How  do  I  set  up  the 
viewing  pipeline?",  "How  do  I  set  up  the  pipeline  to  create 
a  drawing  or  views?",  or  "How  do  I  use  the  pipeline  to 
provide  for  scaling?". 


Issues  >  Presentation  Entities  for  PDES 


page  ^ 


Issues 

1.  Alan  Peltzman,  Inter  CAD  Corp.,  (301)  224-2926 

a.  On  page  4,  the  diagram  incorrectly  shows  the  origin  of 
the  UVW  coordinate  system  to  be  different  from  the  view 
reference  point.  This  contradicts  the  rest  of  the 
document,  which  states  that  the  origin  of  the  UVW  is  the 
View  Reference  Point. 

RCW  response:  You're  right,  thanks. 

b.  On  page  5,  section  2.2.2,  the  N-axis  needs  to  be 
explicitly  defined. 

RCW  response:  See  "Implementor's  Guide". 

c.  The  view  matrix  on  page  5,  section  2.2.4,  should  be 
eliminated.  Redundant  information. 

RCW  response:  This  was  included  for  computational 

efficiency.  It  is  certainly  redundant  and  could  be 
eliminated. 

d.  on  page  8,  section  2.3.3,  UMIN,  UMAX,  VMIN,  and  VMAX 
need  to  be  explicitly  defined. 

RCW  response:  See  "Implementor's  Guide". 

e.  As  a  side  issue,  please  ask  PBIGS  how  they  propose  to 
deal  with  light  source  information.  This  is  very 
important  in  shading  applications. 

RCW  response:  This  will  be  part  of  the  comments  to 
PHIGS. 


2.  Don  Hemmelgarn,  International  TechneGroup  Inc., 

(513)  576-3900 

a.  Requirement  for  Drafting  (Drawing)  Coordinates. 

There  is  a  required  presentation  concept  which  is  not 
addressed  by  the  document  "DRAFT  of  Presentation 
Entities  for  PDES."  This  is  the  concept  of  an 
independent  coordinate  space  for  the  location  of  views 
and  the  definition  of  drawing  entities.  This  "drawing 
space"  coordinate  system  will  need  only  to  be  a  2-D 
coordinate  system.  One  requirement  for  this  capability 
would  be  the  specification  of  the  extents  of  the  drawing 
or  drawing  size. 

One  possible  way  to  do  this  in  the  context  of  the  given 
viewing  pipeline  would  be  to  locate  views  and  specify 
drawing  entities  in  NPC  coordinates.  This  would  then 


allow  the  NPC  space  to  map  exactly  to  the  drawing.  This 
would  require,  however,  that  NPC  extents  be  made  more 
flexible  by  allowing  0.0  to  1.0  in  one  direction  and  0.0 
to  some  value  in  the  other  direction  to  allow 
rectangular  drawings. 

RCW  response;  See  "Implementor's  Guide". 

b.  Scaling 

The  document  does  not  include  any  details  on  view 
scaling.  Zt  would  be  helpful  to  see  examples  of  how 
view  scaling  is  accomplished  in  the  pipeline,  in 
addition  to  how  a  traditional  view  matrix  and  scale 
factor  would  be  mapped  into  the  proposed  viewing 
pipeline . 

RCW  response:  See  "Implementor's  Guide". 

c.  Device  Coordinates 

My  feeling  is  that  the  Display  Transformation  need  not 
be  specified  or  included  as  part  of  a  product  data 
exchange  file.  For  a  post>processor ,  it  is  better  to 
work  with  NPC  coordinates  and  map  these  to  the 
particular  device  configuration  that  he  uses. 

RCW  response:  My  feeling  is  that  the  specification  of 
the  complete  viewing  pipeline  from  model  coordinates  to 
the  display  surface  must  be  provided*  for.  However, 
remember  that  since  the  Presentation  is  not  actually 
part  of  the  Product  Definition,  it  can  be  treated 

optionally.  Thus,  if  a  vendor  wishes  to  work  with  NPC 

coordinates  and  ignore  the  Device  Transformation,  that 
is  his  prerogative.  The  important  point  is  that  the 
specification  is  complete  if  the  user  wants  to  use  it. 

d.  Character  Set 

It  should  be  mentioned  that  the  ASCII  character  set  is 
to  be  used  in  defining  text  strings.  For  clarity,  we 
should  spell  out  the  difference  between  character  set 
and  text  font.  These  concepts  have  been  muddled  in 
IGES.  Text  font  is  merely  a  way  of  presenting  the 
characters  in  the  defined  character  set.  Also,  there 
will  need  to  be  a  set  of  special  symbols  (to  be  defined 

by  drafting  application  and  others)  added  to  the 

standard  character  set. 

RCW  response:  See  "Implementor's  Guide". 
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3.  Martin  Marietta  Aerospace,  Orlando,  FL 

a.  Optional  Presentation  Section. 

Will  the  entire  Presentation  section  be  made  optional  in 
a  file?  This  would  be  desirable  from  the  standpoint  of 
passing  product  definition  data  from  design  to 
manufacturing,  where  display  characteristics  and 
"drawing"  information  such  as  formats  are  not  needed. 
If  this  is  the  case,  presentation  entities  should  not 
contain  information  needed  in  geometry/manufacturing 
instructions  such  as  text. 

RCW  response:  As  presently  envisioned,  Presentation 
entities  are  not  mandatory;  however,  they  will  remain 
quite  important  for  those  who  use  FOES  in  the  same 
fashion  as  they  are  now  using  IGES.  With  regard  to 
text,  it  must  exist  both  in  and  out  of  the  presentation 
entities.  Text  such  as  dimensions  and  notes  that  are 
part  of  a  drawing  are,  by  definition,  part  of  the 
presentation  set,  while  text  such  as  process  plans  and 
technical  documents  are  not.  It  would  probably  be  a 
good  idea  to  allow  the  text  string  (T_STR  in  the  TEXT 
entity)  to  be  optionally  a  pointer  so  notes  and  comments 
that  are  part  of  the  product  definition  could  be 
referenced  and  displayed  on  the  screen  or  a  drawing. 

b.  Colors  and  surface  attributes. 

The  color  table  and  color  attribute  appear  to  be 
redundant  and  also  the  color  table  will  not  allow 
precise  color  specification.  See  Ted  Berenyi's  work  on 
RGB  vs  HSL,  etc.  Again,  colors  should  be  assignable  to 
bodies  in  solids;  therefore,  they  should  be  available 
outside  the  presentation  part.  The  same  argument 
applies  to  filling.  The  fill  options  must  also  be 
expanded  eventually  to  include  surface  texture  display 
attributes,  as  well  as  glossiness,  translucency/ 
transparency  and  light  source  information. 

RCW  response:  It  is  generally  agreed  that  the  ELS  color 
model  is  more  "convenient"  for  people  and  the  RGB  model 
is  more  convenient  for  computer  hardware.  Since  one  can 
easily  convert  back  and  forth  between  the  two,  it  was 
decided  to  specify  only  one  in  the  interest  of 
simplicity.  Since  the  PDES  file  is  presumably  to 
transfer  data  between  computer  hardware  rather  than 
people,  the  RGB  model  was  selected.  The  COLOR_ATTR 
entity  (para.  4.9)  provides  a  means  for  specifying  a 
single  color  (to  about  6  or  7  decimal  places  for  each  of 
the  red,  green,  and  blue  components).  The  COLOR_TABLE 
entity  acknowledges  that  display  hardware  can  only 
display  a  limited  number  of  different  colors  at  any  one 
time,  and  that  these  displayable  colors  are  typically 
defined  in  a  hardware  color  look-up  table.  The  number 


of  different  colors  depends  on  the  number  of  pixel 
planes  in  the  hardware  and  on  how  these  planes  are  used. 
Hence,  each  index  (IND_1...IND  N)  is  a  pointer  to  a 
specific  color  -  each  of  'which  Ts  defined  with  more 
precision  than  is  available  in  the  hardware. 

With  regard  to  assigning  colors,  fill  patterns,  etc.  to 
geometrical  entities,  we  must  remember  that  the  object 
of  PDES  is  to  exchange  product  definition  data.  By 
contrast.  Presentation  is  intended  to  aid  in  viewing  a 
model,  but  in  general  has  nothing  to  do  with  its 
definition.  Hence,  it  is  important  to  separate  the  two 
and  not  allow  them  to  become  intermixed  as  they  are  in 
ZGES.  On  the  other  hand,  attributes  such  as  surface 
texture,  glossiness,  and  translucency/transparency  could 
easily  be  either,  or  both.  Product  Definition  and 
Presentation.  These  latter  attributes,  along  with  light 
source  (which,  again,  is  Presentation),  were  discussed 
by  the  Logical  Layer  Group,  and  it  was  decided  to  add 
them  at  a  later  time.  It  is  now  recommended  that  they 
be  included  in  a  recommendation  to  PHIGS. 
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width  so  dsrivsd  is  further  scaled  by  ■ultiplyin9  it  by  the 
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RIGHT  Means  in  the  direction  of  the  CHARACTCR  BASE  VECTOR. 
LEFT  Means  IBO-deqrees  (roM  the  CHARACTER  BASe  VECTOR. 

UP  Means  in  the  direction  of  the  CHARACfER_u4  VECTOR. 
DOWN  Means  IBO-deqrees  froM  the  CHABACTER  UP  VECTOR. 
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orientation  vector*.  The  centerline  skews  to  reaain 
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(RESOURCE) 
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PDES  SCHEMA 


—  START  OF  PRESENTATION  ENTITIES 

—  VERSION  0. 1 

—  AUTHOR  WINFREY 

ENTITY  picture; 

NOROLE 

name  ;  OPTIONAL  t_name  WHERE  UNIQUE; 

ROLE 

i ni t i al _vi sual _appearance  :  SET  OF  REFER <vi sual _dppearance) 
picture_part  ;  DEPENDENT  SET  OF  REFER (pi cture_part ) ; 

END; 


ENTITY  picture_part ; 

NOROLE 

name  r  OPTIONAL  t  name  WHERE  UNIQUE; 

ROLE 

pi cture_part_appedrance  :  SET  OF  REFER (vi sual _appearance) ; 
element  :  LIST (0  TO  *)  OF  REFER (pi cture_element) ; 

END; 


entity  curve_-font; 

NOROLE 

name  :  OPTIONAL  t  name  WHERE  UNIQUE; 

ROLE 

pattern  :  REFER  (cur ve_-f on t  bi  t_pattern> ; 
END; 


ENTITY  curve_-f ont_bi t^pattern; 

NOROLE 

name  :  OPTIONAL  t_name  WHERE  UNIQUE; 

ROLE 

num_0'f_bits  :  INTEGER; 

bit_pattern  :  ARRAY  ( I ;  num_o-f  _bi  ts)  OF  t_bit; 
END; 


ENTITY  curve_width; 

NOROLE 

name  :  OPTIONAL  t  name  WHERE  UNIQUE; 
ROLE 

width  !  t_magnitude; 

END; 


ENTITY  curve_color; 

NOROLE 

name  :  OPTIONAL  t  name  WHERE  UNIQUE; 
ROLE 

color_value  :  REFER (col  or ) ; 

END; 
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PDES  SCHEMA 


ENTITY 
OROLE 
name 
ROLE 


Bdge_'f  ont ; 

:  OPTIONAL  t_name  WHERE  UNIQUE; 


edge_-f  ont_pattern  :  REFER  (curve_-f ont ) 


END; 


ENTITY  edge_color; 

NOROLE 

name  :  OPTIONAL  t_name  WHERE  UNIQUE; 
ROLE 

color_value  :  REFER (color ) ; 

END; 


ENTITY  edge.width; 

NOROLE 

name  :  OPTIONAL  t_name  WHERE  UNIQUE; 
ROLE 

width  :  t_magnitude; 

END; 


ENTITY  interior_style; 
NOROLE 


name  ;  OPTIONAL  t.name  WHERE  UNIQUE; 

OLE 

5tyle_de-f  ini  tion  :  REFER  <  inter i or_styl e.def  ini  ti on) 


END; 


ENTITY  interior_color ; 

NOROLE 

name  ;  OPTIONAL  t  name  WHERE  UNIQUE; 
ROLE 

color  value  :  REFER (col or ) ; 

END; 


ENTITY  uv_window; 

NOROLE 

name  ;  OPTIONAL  t_name  WHERE  UNIQUE; 
ROLE 

clip  :  t_cl i p_indi cator ; 
u_min,  u_ma>! , 

v_min,  v_ma:!  :  t_magnitLide; 

END? 
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PDES  SCHEMA 


ENTITY  npc_viev«port ; 

NOROLE 

name  :  OPTIONAL  t  name  WHERE  UNIQUE; 
lOLE 

X  _mi n ,  X  _max , 
y_min,  y_max , 

z_min,  s_max  :  t_magni tude; 

end7 


ENTITY  view_mapping  transform; 

NOROLE 

name  :  OPTIONAL  t  name  WHERE  UNIQUE; 

ROLE 

clip_front  ;  t_magnitude; 
clip_back  ;  t_magni tude; ; 
view_plane_di stance  :  t_magnitude; 
uv_window  :  REFER (uv_window)  ; 
npc_viewport  i  REFER (npc^viewport) ; 
projection_type  :  t_projection_type_code 
project ion_reference  :  REFER (pi ace) ; 

END; 


ENTITY  vi ew_trans-f orm; 

NOROLE 

name  :  OPTIONAL  t  name  WHERE  UNIQUE; 
ROLE 

up  :  REFER (direction) ; 
view_plane_normal  :  REFER (direct i on) ; 
view  reference  :  REFER (pi ace) ; 

END; 


ENTITY  color; 

NOROLE 

name  ;  OPTIONAL  t  name  WHERE  UNIQUE; 
ROLE 

red  :  t_magnitude; 
blue  :  t^magnitude; 
green  ;  t^magnitude; 

END; 


ENTITY  restricted  text; 

NOROLE 

name  :  OPTIONAL  t  name  WHERE  UNIQUE; 
ROLE 

location  :  REFER (pi ace) ; 
basic.text  :  STRING; 

appended_tex t  :  LIST (0  TO  *)  OF  STRING; 
outline  ;  t_paral 1  el ogram; 

END; 
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PDES  SCHEMA 


ENTITY  normal  text; 
NOROLE 


name  :  OPTIONAL  t  name  WHERE  UNIQUE; 
OLE 

location  :  REFER (place) ; 
basic_text  ;  STRING; 

appended_text  :  LIST(0  TO  *)  OF  STRING 
outline  :  t_paral lelogram; 


END; 


ENTITY  pattern;  —  Noted) 

NOROLE 

name  i  OPTIONAL  t  name  WHERE  UNIQUE; 
END; 


ENTITY  solid;  —  Noted) 

NOROLE 

name  :  OPTIONAL  t_ndme  WHERE  UNIQUE; 
END; 


ENTITY  hollow;  —  Note ( 1 ) 

NOROLE 

name  i  OPTIONAL  t  name  WHERE  UNIQUE; 
END; 


entity 

NOROLE 

name 

END; 


empty;  —  Noted) 

:  OPTIONAL  t^name  WHERE  UNIQUE; 


ENTITY  char_-font;  —  Noted) 

NOROLE 

name  :  OPTIONAL  t  name  WHERE  UNIQUE; 
END; 


ENTITY  text_color;  —  Noted) 

NOROLE 

name  ;  OPTIONAL  t  name  WHERE  UNIQUE; 
END; 


ENTITY  te;: t_al  1  i gnment ;  —  Noted) 
NOROLE 

name  :  OPTIONAL  t  name  WHERE  UNIQUE; 
END; 
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PDES  SCHEMA 


ENTITY  char_expansion;  —  Noted) 
NOROLE 

name  :  OPTIONAL  t_name  WHERE  UNIOUE; 
-.ND; 


ENTITY  char_height;  —  Noted) 

NOROLE 

name  :  OPTIONAL  t.name  WHERE  UNIQUE; 
END; 


ENTITY  char_spacingi  —  Noted) 

NOROLE 

name  :  OPTIONAL  t_name  WHERE  UNIQUE; 
END; 


ENTITY  char_orientation;  —  Noted) 
NOROLE 

name  i  OPTIONAL  t_name  WHERE  UNIQUE; 
END; 


ENTITY  te«t_path;  —  Noted) 

NCROLE 

name  ;  OPTIONAL  t_name  WHERE  UNIQUE; 
END; 


ENTITY  text_preci»ion;  —  Note<l) 
NOROLE 

name  :  OPTIONAL  t_name  WHERE  UNIQUE; 
END; 


ASSOCIATION  text_element; 

OF  (text,  tex t_appearance (  ♦  )); 

—  speci'fying  the  cardinality  o-f  an  association  has  not  been 

—  settled.  This  tries  to  say  that  one  "text"  may  be  associated 

—  with  many  "text^appearance" , 

END; 


ASSOCIATION  curve_el ement ; 

OF  (curve,  curve_appearance <  ♦  )); 
END; 


ASSOCIATION  sur-f ace_el ement ; 

OF  (sur-f  ace,  sur-f  ace_appearance  (  -*  >); 
END; 
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PDES  SCHEMA 


CLASS  picture_element 
(definition  element 


OF 

y  picture_part ) 


CLASS  vi sual _appearance  OF 

( tex t_appearance ,  surf ace_appeardncey  curve_appearance, 
view_operation)  ; 


CLASS  surf ace_appearance  OF 

(edge.appearance ,  interior_appearance) ; 


CLASS  curve_appearance  OF 

(curve_font,  curve_colory  curve_width) ; 


CLASS  tex t_appearance  OF 

(char_font,  text_color,  text_al 1 i gnment ,  char_expansi on , 
char_height,  char_spaci ng ,  cbar_or i entati on ,  text_path, 
text^preci si  on ) ; 


CLASS  vi ew_operat i on  OF 

( vi ew_transf orm,  vi ew_mappi ng_transf orm, 
wor k_stat i on^transf orm)  ; 


ASS  def ini tion_element  OF 
(curve_el ement y  surf ace_el ement , 


text^element) ; 


CLASS  inter ior_appearance  OF 

( i nter i or^styl e y  interior_color) ; 


CLASS  edge_appearance  OF 

(edge_fonty  edge_color,  edge_width) ; 


CLASS  i nter i or _styl e_def i ni t i on  OF 

(pattern,  solid,  hollow,  hatch,  empty); 


CLASS  text  OF 

(normal _tex t ,  restr i cted_tex t )  ; 


NOTE (1 )  These  entities  require  ROLE  attributes,  but  the  NIAM 
model  did  not  specify  what  those  ROLE  attributes  are 
This  will  have  to  be  corrected  after  L.L.  Initiation 
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Appendix  C3 
Task  1 


C3.1 
C3.2 
C3.3 
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C3.5 


Flat  Plate  Mechanical  Part  Application  Model 

(DISCIPLINE) 


Initial  Model  and  Documentation 

Scemarios  for  Presentation  of  Flat  Plate  with  Holes 
Qualified  Model  (NIAH) 

Global  Model  (NIAM) 

Specification  Model  (DSL) 
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Appendix  C3.1 
Task  1 

Flat  Plate  Mechanical  Part  Model  Initial  Model  and  Documentation 

(DISCIPLINE) 


Fl«t  Plate  Reference  Model 


Scope  of  the  model 

For  the  purposes  of  this  initial  document,  flat  plates  are 

considered  to  have  the  following  characteristics! 

-  Plate  has  two  major  (large)  faces,'  a  top  and  a  bottom 

-  Uniform  thickness |  i.e.  top  and  bottom  faces  are  parallel 

-  The  top  and  bottom  faces  are  not  required  to  have  congruent 
peri met ers 

The  thickness  is  small  realtive  to  the  top  and  bottom  face 
dimensions 

-  For  any  traverse  from  top  to  bottomface,  along  the 
intersection  of  an  arbitrary  plane  perpendicular  to  the  top 
and  bottom  faces,  only  one  "side  face"  will  be  encountered. 

-  Only  round,  through  holes  of  uniform  diameter  are  allowed. 

~  Edge  conditions,  e. g.  chamfer/radius  specifications  will  be 
treated  as  attributes.  If  the  ehamfers/radi i  are  large  enough 
to  require  more  detailed  definition,  they  are  outside  the  scope 
of  this  model. 


Definitions: 


Flat  Plate 

This  is  an  entity  that  is  the  "top  of  the  tree"  in  the 
definition  of  a  single  piece  part.  Under  this  entity  is  all  the 
definitional  information  for  the  part. 


Face 

Face  is  a  topological  entity.  It  is  essentially  a  bounded  surface. 
The  boundaries  are  topological  entities,  edges,  with  their  end 
points  defined  by  vertices.  This  is  the  relatively  standard  BREP 
notation. 


Surface 

The  geometric  (mathematical)  entity  that  defines  the  shape  of  a 
face. 


D«t  um 

One  of  three  planes  that  in  principle  define  the  coordinate 
system  of  the  plate.  The  three  planes  are  mutually  perpendicular 
and  intersect  in  a  point.  That  point  is  the  origin.  The  planes 
or  some  manifestation  of  them  are  referenced  as  datums  in 
tolerances  and  other  entities. 


Angular  *  Location  4-  Geometric  tolerances 

These  tolerances  are  defined  in  the  tolerance  model.  Their 
presence  in  this  model  is  to  indicate  the  relationships  of 
tolerances  to  the  flat  plate  part. 


Heat  Treat  Specification 

A  specification  defined  by  industry  groups  or  a  company  -that 
defines  a  specific  set  of  heat  treatment  procedures  and  results 
to  be  applied  to  a  part. 


Drawing 

A  manifestation  in  human  readable  form  of  some  of  the 
definitional  information  about  a  part. 


Process  Plan 

This  is  a  grouping  of  all  the  information  needed  to  manufacture 
the  plate  from  raw  material. 


30  Views 

These  views  are  20  projections  of  the  complete  30  model 
definition  on  a  viewing  plane  with  or  without  hidden  line  and 
surface  removal.  They  are  used  for  many  purposes,  such  as 
instruction  sheets  for  the  shop. 


Cross  section  views 

These  views  are  20  representations  of  a  part  as  though  a  plane 
has  cut  away  the  portion  of  the  part  nearest  the  viewer.  These 
may  also  be  used  for  many  purposes  such  as  instructions, 
visualization  or  drawings. 


Profile  views 


These  views  are  20  representations  of  a  part  from  standard 
viewpoints.  Thes#  might  be  used  on  a  drawing  or  by  a  process 
planner  to  nest  plate  parts  in  raw  material  for  NC  burners. 


Edg* 


Th«  topological  antity  that  bounds  a  facs.  It  is  assent ially  a 
gaomatric  curve,  bounded  by  and  points  (vertices). 


Curve 

The  geometric  (mathematical)  entity  that  defines  the  shape  of  an 
edge. 


VerteK 

The  topological  entity  that  bounds  an  edge.  It  is  essentially  a 
geometric  point. 


Coordinate  Point 

The  geometric  (mathematical)  entity  that  defines  a  location  in 
space. 


Hole 

P  feature  of  the  flat  plate.  It  is  defined  by  its  diameter, 
centerline  vector  and  a  coordinate  point  contained  on  a  surface 
of  the  plate.  This  feature  entity  may  be  required,  in  some 
applications  to  be  transformed  into  topology  and  geometry,  e. g. 
an  assortment  of  faces  and  edges,  but  for  purposes  of  model 
definition,  this  one  is  informationally  complete  within  the 
scope  of  the  model. 


Surface  texture 

This  is  an  entity  that  describes  the  allowable  deviation  from 
perfection  (at  the  micro  level)  of  a  surface.  The  exact 
definition  is  given  by  ANSI  and  ISO  standards. 


Vector 

A  geometric  (mathematical)  entity  that  defines  a  direction  in 

space. 


Size  tolerance 

One  of  the  tolerance  entities  that  applies  to  the  diameter  of  a 
hole  feature. 


Process  I nst  ruct i ons 


This  class  of  information  covers  machining  steps,  feeds  & 
speeds,  NC  programs,  surface  treatment  instructions  and  such. 
This  area  is  quite  undefined  as  structured  information  today. 


Configuration  management 

This  is  the  information  the  enterprise  requires  to  control  the 
part.  Examples  aret 

design  control  responsibility 

release  status 

effect i vit y 

designer 

checker 

approvals 


Some  of  these  items  might  apply  to  portions  of  the  part 
definition  <e. g.  effectivity  of  material  spec.)  as  well  as  to 
the  total  part  definition. 


Appendix  C3.2 
Task  1 

cernarlos  for  Presentation  of  Flat  Plate  with  Holes 

(DISCIPLINE) 
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Submitted  by:  Don  Hemmelgarn,  ITI 

(513-576-3931) 


At  the  June  *85  meeting  of  the  PDES  Logical  Layer  Initiation  Task  Group  it  was 
decided  to  focus  our  entity  integration  efforts  on  a  particular  mechanical 
application  to  put  more  ’meat*  into  the  results  of  that  work.  The  application 
chosen  was  the  design  of  flat  plates  with  round  holes.  It  was  also  agreed  that  a  list 
of  scenarios  for  viewing  flat  plate  models  may  be  helpful  in  identifying  data 
requirements  (eg.  associativities)  for  the  logical  layer  integration  effort.  This 
document  represents  a  first  shot  at  briefly  describing  various  ways  flat  plate 
models  may  need  to  be  presented  to  the  mechanical  designer  (user  view).  The 
intent  is  to  provide  information  meaningful  to  the  integration  of  flat  plate, 
wireframe  and  presentation  entities  proposed  for  PDES.  However,  my  feeling  is 
this  will  more  likely  serve  as  impetus  for  some  good  discussions  concerning  PDES 
entity  requirements.  For  this  reason  I  have  included  some  words  about  required 
associativities,etc.  with  some  of  the  presentation  descriptions. 

This  is  by  no  means  an  exhaustive  list  of  viewing  options  for  flat  plate  design. 
Therefore,  I  welcome  the  results  of  any  add/modify/delete  operations  you  may 
wish  to  perform  on  this  list. 


Each  viewing  scenario  appears  as  a  numbered  statement  with  special  data 
requirements  shown  in  italics. 

(1)  Need  ability  to  present  one  to  six  orthogonal  views  of  the  plate,  at  various 

scales  and  positions.  This  is  starting  point  for  description  of  a  fiat  plate 
drawing.  Requires  view  scaling  and  independent  view  positioning,  in  addition  to 
identification  of  'model'  geometry  to  be  transformed  thru  the  view(s). 

(2)  Must  be  able  to  display  only  outside  edges(perimeter)  of  the  plate.  This  is 

useful  for  determining  material  utilization.  Requires  association  of  perimeter 
attribute  to  some  plate  edges. 

(3)  Similar  to  (2),  display  only  cut  edges;  perimeter,  cut-outs,  and  non-drilled  holes 

for  generation  of  N/C  flamecutting  data.  Requires  association  of  'cut'  edges. 

(4)  Display  a  cross-section  thru  the  plate  model  at  a  given  location  and  orientation. 

Requires  knowledge  of  holes  or  cut-outs  and  view  clipping  capability. 

(5)  Be  able  to  display  or  not  display  geometry  representing  threads.  Requires  entity 

blanking  and  association  of  thread  geometry  with  holes. 

(6)  Display  surfaces  with  like  finish  specifications  in  the  same  color.  At  this  point, 

this  means  display  of  color  on  wireframe  plate  edge  entities.  Requires 
association  of  surface  finish  with  plate  geometry  and  ability  to  assign  colors  to 
selected  group  of  entities. 

(7)  Display  rotated  and/or  perspective  views  of  the  plate  geometry. 

(8)  Hidden  lines.  Either  not  display  hidden  lines  or  display  them  as  dashed  lines. 

Requires  ability  to  handle  view  dependent  fonts  and  inclusion  of  geometry  in 
onejeveral.  or  all  defined  views. 

(9)  Display  only  drilled  holes  and  their  center  points  for  point  to  point  machining 

operations.  As  in  (S).  requires  knowledge  of  process  to  generate  hole  as  an 
attribute  for  the  hole,  as  well  as  entity  blanking. 

(10)  Display  or  blank  a  point  with  an  associated  text  string  representing  the  C.G.  of 

the  plate.  Requires  a  point  entity  associated  with  the  plate  and  ability  to 
associate  text  entity  with  geometry. 

(11)  Display  or  blank  an  arrow  with  associated  text  string  indicating  material  grain 

direction. 

(12)  Display  the  following  textual  information  along  with  the  views  of  the  plate,  at 

a  specified  position; 

-  Part  number 

-  Revision  number  or  code 

-  Effectivity  date 

-  Material  specification 

This  requires  text  entity  with  ability  to  orient  text  string  and  define  text 
characteristics  (height.  width.etc.).  Also  requires  association  of  this  data  with  the 
part  being  displayed. 


Appendix  C3.3 
Task  1 


Flat  Plate  Qualified  Model  fNIAM^ 


(DISCIPLINE) 
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Apendix  C3.4 
Task  1 


Flat  JPlate  global  Model  (VlMi) 


(DISCIPLINE) 
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Appendix  C3.5 
Task  1 


Flat  Plate  Specification  Model  fPSLl 


(DISCIPLINE) 


17 


F’DES  SCHEMA 


(DRAFT  01/J3/19B6) 


—  START  OF  FLAT  PLATE  ENTITIES 

this  -function  computes  •  face  based  on  the  input  bodies  and  the 
parameter  value  which  normally  would  be  O.O(bottom)  or  l.O(top). 


FUNCTION  cal c^uni -f orm^body_f ace 
(pi  us: uni f orm^body; 

minus:LI5T(0  TO  *>  OF  uni f orm^body; 
par am: REAL) 

I  face: 

BEGIN; 


— >  input/positive  body 

input /negative  body  array 
~  input /parametric  value 
—  returned/face 


how  this  is  done  is  left  to  the  reader. 


END; 


—  this  function  computes  the  side  face  of  a  uniform-body  as 

—  specified  by  side-number. 

FUNCTION  cal c_uni f or m_body_si de 

(plus:un:f orm_body)  —  input/positive  body 

t  LISTd  TO  a)  OF  face;  —  r eturned/f ace 

BEGIN; 

~  how  this  is  done  is  left  to  the  reader. 

END; 


—  the  uniform-body  is  a  constructive  solid  based  on  a  sweep  of  a 

—  planar  2d  closed  curve. 

ENTITY  uni f orm^body; 

NOROLE 

name  i  OPTIONAL  t  name  WHERE  UNIQUE; 

ROLE 

outline  :  REFER  (  cl osed_pl anar_curve2  ); 

thickness  i  t  magnitude; 

END; 


ENTITY  uniform  fl 
NOROLE 

name 

ROLE 

■  positive^body 
negati ve^body 

top 

bottom 

Bide 

END; 


at.plate; 

t  OPTIONAL  t.name  WHERE  UNIQUE; 

I  REFER  (  uniform_body  >; 

I  LIST(0  TO  *)  OF 

REFER  (  uniform^body  ); 

I  calc_unif orm_body_f ace 

(positive.bodyynegati ve_body, 1.0); 

I  cal c.unif orm^body^f ace 

( pos i t i ve_body , negat i ve_body ,0.0); 

I  calc_uniform_body_side_f ace 
(posi ti ve.body) ; 


END  (  •  pdes  schema  •  ) ; 


Appendix  C4 
Task  2 


Electrical  Schematic  Application  Mode! 
(DISCIPLINE) 


C4.1  Discipline  Model  2md  Documentation 
C4.2  Qualified  Model  (NIAM) 

C4.3  Global  Model  (NIAM) 
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Appendix  C4.1 
Task  2 


Electrical  Schematic  Discipline  Model  and  Documentation 


(DISCIPLINE) 
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Model  notes  for  reviev/ers 
C.  H.  Parks 


Inasmuch  as  the  model  intended  use  is  a  logical  view  of  the  data,  independent 
of  existing  systems  or  methods,  for  development  of  a  neutral  product  data 
exchange  structure,  the  reviewer  is  asked  to  keep  in  mind  several  important 
modeling  constraints. 

The  entities  and  attributes  are  to  reflect  the  data  inherent  in  schematic,  as 
opposed  to  the  information  conveyed  by  a  schematic.  An  example  is  that  the 
User  View  preceeding  the  logical  IDEF-1  model  describes  a  netlist.  The  netlist 
is  here  recognized  as  information  assembled  by  a  query  against  schematic  data. 

In  turn,  the  model  must  be  capable  of  supporting  such  a  query.  Elements  of 
information  found  in  the  netlist  are  found  in  the  Network,  Symbol  Connection 
Place  and  Symbol  Instance  entity  classes. 

The  model  must  exist  independent  of  implementations.  The  entity  classes  in 
the  logical  model  must  be  equally  valid  for  a  pencil-drawn  schematic  ‘or  a 
CAE  system  with  nodal  data  structures.  The  Text  Template  entity  found  in  the 
I6ES  PWB  model  has  no  validity  under  this  rule  and  has  not  been  included  in 
this  model.  The  data  concept  of  a  "place  where  a  connectior  line  can  terminate" 
would  be  valid,  and  has  been  included  as  a  Line  Connection  Place  entity. 

The  model  must  provide  for  a  union  with  other  related  models.  This  has 
resulted  in  entity  classes  which  also  belong  in  other  models,  but  are  in¬ 
cluded  to  show  the  key  migration  and  the  relation  classes.  The  entities 
"Product  Assembly  Definition"  and  "Component  Part"  are  examples  of  such 
entities  from  other  models.  • 

The  entity  classes  involved  in  circuit  analysis  have  been  developed  more  than 
necessary  for  a  schematic  because  of  the  high  degree  of  coupling  with  schematic 
entities.  While  packaging  requires  information  from  the  schematic  data, 
analysis  is  an  interactive  data-exchange  with  the  schematic.  No  requirement 
for  conveying  analysis  data  in  a  product  assembly  structure  should  be  assumed 
by  this. 

Several  entities  classes  have  been  created  as  part  of  the  normalization 
processes.  These  entities  are  not  included  in  the  Overview  FEO.  An  example 
is  Electrical  Symbol  Instance,  which  provides  a  home  for  the  Reference 
Designator  (key)  attribute.  This  attribute  can  be  null  for  some  Symbol 
Instances  (e.g.,  utility  symbols),  creating  a  separate  entity  class. 

The  author's  opinion  is  also  offered  that  a  schematic  (all  of  this  model)  is 
not  part  of  a  "product  definition":  Schematics  exist  as  a  design  aid  and  as 
reference  documentation. 


(VI 


A/ESCH/C-M 


ELECTRICAL  SCHEMATIC  APPLICATIOH  -  USER  VIEW 
Draft  1/31/85.  C.  H.  Parks 


I.  Definition 

The  schematic  Is  a  symbolic  representation  of  component  parts  and 
their  electrical  connections.  The  schematic  may  be  for  any  hier¬ 
archical  level  of  product  definition,  and  becomes  part  of  the  packaging 
requirements  at  that  level.  Schematics  may  also  contain  details  of 
related  mechanical  nature  (e.g..  heat  sinks,  connectors,  etc.)  and 
transmission  of  optical,  magnetic  or  microware  energy. 

II.  Inputs  (sources  of  design  constraints) 


0  Block  diagram,  system  or  subsystem  with  target  block  identified 

0  Interface  requirements  (e.g..  signals  and  power) 

0  Mechanical  package  requirements  (e.g..  chip,  hybrid  microelectronic 
assembly  or  printed  board  size  and  mounting) 

0  Design  (and  product)  constraints  and  characteristics  (e.g.. 
specifications,  system  equations,  test  requirements) 

0  Schedules  and/or  budget 

0  Approved  (or  preferred)  parts  lists 

0  Symbol  set  and  drafting  standards 

III.  Items  schematic  relates  to  during  design 

0  Design  block  diagram 

0  Boolean  operators 

0  Detail  equations/transformations 

0  Static  or  dynamic  models  and  simulations 

IV.  Schematic  constituents 

SYMBOLS:  a  2-dimensiona1  figure  commonly  accepted  as  a  representation 
for  a  part's  functionality. 

SYMBOL  IDENTIFICATION:  part  family,  part  number,  part  values,  part 
tolerance  and  reference  designator  (identifies  an  instance  of  the 
part,  and  may  be  later  changed  to  match  physical  package  assignment) 

SYMBOL  CONNECTION  P0INT§:  indicates  where  connections  to  symbol  can 
occur. 


A/ESCH/B-ll 


SYMBOL  CONNECTION  POINT  IDENTIFICATION:  Function  code  (e.g.,  Q, 

Q»  01.  02.  VCC.  GNO)  and  pin  number  (the  latter  may  be  different 
after  physical .design  is  completed) 

JUNCTION  POINT:  Symbol  (usually  a  filled  small  circle)  Indicating 
an  electrical  union  of  2  or  more  connection  lines 

CONNECTION  LINES.  SINGLE:  a  2-0  line  or  string  between  symbol 
connection  points  or  junction  points 

CONNECTION  LINES.  BUS:  a  2-0  line  or  string  (usually  bold  or 
highlighted)  which  represents  a  collection  of  connection  lines 

CONNECTION  LINE  IDENTIFICATION:  signal  name  (single),  bus  name  or 
trunk  ID  (bus) 

UTILITY  SYMBOLS:  non-part  symbols  for  simplification  purposes 
(e.g..  off  page  connector,  ground  connection  .  power  connection, 
test  point,  antenna) 

FUNCTION  SYMBOL:  Identification  of  (usually)  ncn-electrical  re¬ 
quirements  or  parts  (e.g..  optical  energy  source,  heat  sink) 

V.  Schematic  outputs 

PICTORIAL:  used  to  review  circuit  design  and  as  part  of  final 
product  documentation 

NET  LIST:  a  topology  derived  by  examining  the  logical  relations 
(links)  created  by  the  connection  lines  (joins).  Resultant  list 
must  be  formatted,  and  contain  Information,  for  each  use  (e.g.. 
physical  packaging  process,  circuit  analysis  methodology,  test 
development  system).  Minimal  net  list  Information  Includes  part 
identification  (which  must  match  Identification  of  parts  In  the 
library  of  each  using  system),  symbol  connection  point  Identification 
and  unique  link  Identification.  May  be  augmented  with  electrical 
characteristics  (waveform,  delay,  etc.K 

BILL-OF-MATERIALS:  a  list  of  parts  cited  In  schematic.  Used  for 
5t'’ii;s  analysis,  packaging  the  physical  circuit  and  In  documentation 
parts  lists. 


V-2 


A/ESCH/B-40-4 


ANALYSIS:  The  modeling  of  the  electrical  functions  on  a  I  INTERSECTION  PLACE:  A  place  where  Connection  Lines*  are 


u 

0) 

o 

O  I 

U  CSJ 

Q. 

<a 

k. 

o  <*. 

o 


• 

in 

•k  3 

k 

44 

Of 

44  44 

o 

>«  k 

Of  u 

ID  U 

44 

I/I 

A  ID 

w  o 

Of 

S  <D 

ID 

44  e 

Q. 

e  k 

a 

k  4--I*-, 

£ 

e  •— 

"O 

ID  a 

0-0  3 

44  c 

Of  Cl 

Of  44 

E 

o 

•k  Of  e 

O  -k 

I/I  Of 

k  ID 

k  in 

44 

e  e  <0 

e 

4k  44 

Of  9 

—  .C 

o  •— 

k.  4-  E 

o 

Of  *3 

w 

3  44 

*4.  in 

•o 

•k 

in  Cl  Of 

a  >1 

O' 

k  >1 

Of 

Ik  Of  4 

44 

4-  C  IM 

Of  IQ 

Of  <»- 

Of  4- 

c 

O  "O  m 

u 

3  O  -k 

k  E 

k  o 

a  ID 

c 

a4-  k 

e 

k. 

e  >iTn 

3 

E  Of  0) 

-44  e 

44  IQ 

Of 

O  4-  >1 

•k 

k-  £  44 

k  o 

k 

■o 

u 

IQ  -4. 

ID  44 

44  «  IQ 

ID 

k  in  IQ 

•S^n 

a44 

a-k 

at 

u  u  e 

O  Of  k 

u 

3 

k 

Of  -k  ID 

Ik 

44  IQ 

e  e 

k  U 

ID 

k-  £ 

O 

U  3  £ 

e  c 

Of  3 

O  k 

4“  U  • 

•k  £  14 

o  o 

>  Ik 

«k 

£ 

o  k  c 

e 

44  -k 

•e* 

u 

U 

U  ID  O 

o 

IQ  k  in 

•o 


o 

u 

at  I/I 

^  *  * 

o  u 

U  01  • 

<a  o.  «s 

<  .  id 


wslA  01 

s|» 

O  ID 


U  •«- 

*■>  at  ** 

IQ  10 


4^  4-1  3J 
I/)  4.1  w 

3 

-O 

*4  f. 

e  •  V. 

01  e  4.) 

U  O  -14  . 

v,  —  >0  VJ 

3  44 

U  ID  V  Ul 

k  E  O  t/l 

O  O  Ml  U 

^  C  .3  4.» 
<0  rr*  «4  I/I 

44  IL  S  ^ 
CO  01 

0)  •  -4 

*4  >1—  U 
O  Cl  V  « 
a.  ^  -o  w 

0)  O  ID 


•  •  I/I  IQ  *4 

-J  >1  o  •- 
s  Ot  •—  3 
X  >  i/t  u 
3  e  >>  k 
o  j: 

«/)  U  Q.  (_l 


IQ 

U  01 

O  i- 

5  W 

>1  °  4* 

iS| 

44  X 


*k  IQ  S 

0 

0 

lO 

£  £ 

«k 

<4 

ij  e 

u 

X  44  U 

s 

• 

D 

E 

m 

ID 

ID 

4—  Of  ID 

3 

«/) 

44 

0  44  in 

0 

in 

L. 

ID 

£  ID 

3 

44 

U  to 

<o 

e 

•c 

e  14  Of 

C 

c 

0)  u 

Q. 

o 

>*-k  £ 

•k 

Of 

«i» 

in  'C  44 

44 

in 

u  w 

0) 

Of 

e 

e 

Of 

I/I 

0  -k  0 

0 

k 

w  u 

o 

0) 

0 

•k  44 

u 

a 

lO  01 

.c 

4C 

E 

k  e 

Of 

44  44  ^ 

at 

C  *0  44 

o  c  u 
to  0/ 
*o  e 
01  4c  e 

I/I  u  o 

2  S 

44  I/I 
4<  0/  4C 
L.  C  t- 

s 

*4  ID  *4 

0/  f  0) 

c  44  e 


44  44  Ol 

Of  e 

E  44  O 

Of  01 

Cl  O  A 

a. 

r—  I/I 

4-  C  Of 

s  O  c 

1/1^3 

u 

<  Of  c 
I/I  o 
k  •»- 

•  •  01  44 

^  44  14 

ui  e  Of 


•I* 

0 

> 

k 

2 

0 

w 

w 

0) 

to 

u 

0 

£ 

u 

c 

19 

4-* 

m 

s 

to 

& 

u  u 

■D 

•c 

u  • 

I/I 

tt-1- 

k 

9  U 

0/ 

•0 

e 

U 

c 

U  to 

e 

0) 

w  w 

0) 

e 

"O 

9 

VI  fO 

I/I 

nC  S 

W 

k 

Q 

e  s 

0 

U  9 

0> 

ID 

i 

0  01 

u 

u 

T? 

E 

W  JS 

o. 

9  (/I 

1 

«/l 

u 

0) 

•o 

0 

e 

Of 

0 

(0 

> 

c 

u 

U  4Q 

0  c 

>> 

k 

0 

4C 

3 

fO 

.9  C 

•DV 

14 

4iA 

U 

•c 

c 

e 

fO 

</l 

U 

VI  0 

to 

>. 

w 

0  *9 

•D» 

W  9 

>» 

^  w 

0) 

C 

£ 

a>  ^ 

u 

u 

Of 

w 

c 

> 

4i/ 

4C  S 

o; 

••  9 

Of 

e 

iC 

v> 

& 

UI 

0^ 

0)  O 

3  • 

*• 

•» 

JS  w 

01 

z  ^ 

UI 

X 

a. 

0  C 

<  w 

0 

u 

Qi 

(9 

k 

0) 

W 

c 

</l  ^ 

a.s 

Cl 

k 

Z'  w 

■ 

^  Jt  Of 
•/>  <o  C 


U  J<  „  “O 
k  oe  Of 

tS  5t! 

9  *4  9  Of 

u  «  wo. 


x  e  X 

Uf  Of  UJ  -o 

^1.  ^  ^ 


^  11^ 
kl  O)  « 
-4  a 
U4  </l 


ni  /r  H 


CONTEXT: 


SCIIFJIATIC  OVERVIEW  FEO  1^  Exposition  A/ESCH, 


SVMOL  LIBRARY  /4 

I  LIBRARY  WAtC/  VER»  |  RROOUCT  ASSY  DCriRITIOR  /I 


NeTson  DATE.  _  WQItKiHi _ JIEADCB _ BAIL  COMTEKT. 

mOJCCT*  REVI  12  June,  1985  mATT _ 

I6ES  SCHEMATIC  LOGICAL  SCHEMA  I  /ff r  ^  JtttMUm - 


Appendix  C4.3 
Task  2 


Electrical  Schematic  Global  Model  fNIAM^ 


(DISCIPLINE) 


C5.1 

C5.2 

C5.3 

C5.4 


Appendix  C5 
Task  2 

Tolerancina  Discipline  Model 
(DISCIPLINE) 

Discipline  Model  and  Docinnentation 
Qualified  Model  (MIAM) 

Global  Model  (NIAM) 

Specification  Model  (NIAM) 


22 


Appendix  C5.1 
Task  2 


Leraneina  Discipline  Model  and  Docxamentation 


(DISCIPLINE) 


23 


Scope 


This  document  provides  the  definition  of  functional 
tolerancing  practices  as  specified  by  A!!SI  yi4.5n-lSo2 
and  1660.  These  specifications  are  considered  to  be 
identical  for  the  purposes  of  this  effort. 


content  for 
and  ISO  1101 
functionally 


This  infornation  model  is  intended  to  completely  define  all  tolerance 
information  specified  by  ANSI  yi4.5fl-1982  and  the  corresponding  isc 
specifications.  Any  deficiencies  should  be  commented  on  in  writing. 


Excluded  from  the  scope 


Computing  tolerances 
Process  tolerances 

Pictorial  representations  of  tolerances 
Dimensioning  practices. 

Non-mechanical  part  tolerances  (e.g.electrical  component  values) 


Assumptions 


Product  models  are  assumed  to  be  3D  v/ireframes  with  surfaces. 


Models  contain  exact  definitions  of  nominal  product  geometry. 

Dimension  information  is  implicit  in  model  geometry. 

Topology  constructs,  where  used  in  this  model,  are  included  to  satisfy 
the  functional  requirements  of  tolerancing.  Since  a  completely  sur¬ 
faced  wireframe  and  a  BREP  model  are  essentially  equivalent,  v;e  have 
adopted  the  3RSP  terminology  of  face,  edge  and  vertex  in  our  tolerance 
model . 


Many  entity  classes  defined  here  are  known  to  be  incomplete.  Usually 
these  classes  are  dependent  on  other  reference  models  that  are  not 
available  yet. 
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General  Definitions 


Product 


An  ite!n(s}  which  is(are)  manufactured,  or  used  in  the  manufacture  of 
an  another  item. 


Model 

A  digital  definition  of  a  product. 


Drawing 

A  pictorial  representation  of  a  product. 


Dimension 

A  numerical  value  which  is  a  measure  of  the  product  implicit,  in  the 
model  geometry. 


notation 


‘There  entities  are  referenced  that  are  not  properly  tolerance  entities 
(e.g.  conic  arc),  those  entity  references  are  marked  with  an  :'o 
definitions  are  provided  for  those  entities. 


The  Pascal-like  "data  structure"  notation  used  herein  is  not  intended 
in  any  way  to  indicate  or  specify  any  particular  physical  representa¬ 
tion  of  the  information.  These  structures  are  included  only  to  clarify 
the  intent  and  content  of  the  information  model. 
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Entity  and  Class  Definitions 


(100)  Geometry 

Geometry  elements  or  entities  are  mathematically  exact  constructs  such 
as  pointSf  lines  and  the  like,  that  represent  topological  elements 
which  are  physically  present  on  a  part.  Geometry  defined  here  is  only 
that  explicitly  contained  in  the  tolerance  information  model. 

Class  of:  Unit_Vector  (101) 

Point_ Vector  (102) 

Vector  (103) 

Curve  (106) 

Coordinate  (107) 

Point  * 

End_class; 


(101)  Unit  vector 

A  sequence  of  three  real  values  that  are  the  direction  cosines  of  c. 
unit  vector.  The  Euclidean  norm  is  exactly  1. 

Start_entity 
i^Cosine 
j^Cosine 
k^Cosine 
End_entity; 


(102)  Point  vector 

A  point  vector  is  three  real  values  that  are  direction  cosines,  a 
coordinate  point  through  which  the  vector  passes  and  a  lenrth  value. 

Start_entity 
Position 
Direction 
Enc_entity; 


(103)  Vector 

A  vector  is  three  real  values  that  are  direction  cosines  and  a  len:jtr. 
value. 

Start_entity 

Direction  :  Unit_Vector  (101) 

Length  :  Real 

End_entity; 


:  Coordinate  (107) 
:  Vector  (103) 


:  Real 
:  Real 
:  Real 
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(106)  Curve 

A  curve  is  a  class  of  entities.  These  entities  are  assunied  to  be 
defined  by  the  information  model  for  3D  surfaced  wire  frames. 

Class  of:  line  * 

circular  arc  * 
conic  arc  * 

End_class; 


(107)  Coordinate 

A  set  of  three  real  values  that  specifies  a  theoretical  position  in 
space. 

Start_entity 

X_coorCinate  :  Real 

y^coordinate  :  Real 

Z_coorcinate  :  Real 

End_entity; 
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(200)  Topology 


Topology  elements  or  entities  are  constructs  that  define  touchable  or 
viewable  portions  of  a  part.  Topology  elements  are  defined  in  terms  of 
geometry  elements  and  other  topology  elements. 


Class  of:  vertex  (201) 
edge  (202) 
face  (203) 

End_class; 


(201)  Vertex 


A  vertex  defines  logical  connectivity  of  edges. 

Start^entity 

Point^reference  :  Point  * 

End_entity; 


(202)  Edge 

An  edge  bounds  a  curve  and  defines  logical  connectivity  of  faces. 


Start_entity 

Curve_reference 

Start^point 

End_?oint 

End_entity; 


:  Curve  (106) 

:  Vertex  (201) 
:  Vertex  (201) 


A  Circular_SQge  and  Planar_edge  are  qualified  types  of  edge. 


(203)  Face 


A  face  is  a  bounded  geometric  surface. 


Start_entity 
Surf ace_reference 
Boundary 

End_entity; 


Surface  * 

Array  (1  to  maxint)  of 
Edge  (202) 


Ci r cular_f ace ,  Planar_face,  Cyl indr ical_f ace,  Disk_face  and 
Runout^face  are  qualified  types  of  face. 


(204)  Circular  edge 

Circular  edge  is  an  obvious  subset  of  Edge  (202) . 
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(205)  Circular  face 


A  circular  face  is  a  subset  of  Face  (203).  A  circular  face  exhibits  a 
circular  cross  section  in  any  plane  perpendicular  to  the  axis  of 
symmetry. 


(206)  Planar  face 

A  planar  face  is  a  subset  of  Face  (203).  A  planar  face  references  a 
surface  that  is  planar  in  the  region  of  interest. 


(207)  Cylindrical  face 

A  cylindrical  face  is  a  subset  of  Face  (203).  The  surface  referenced 
by  the  face  must  be  cylindrical  in  the  region  of  interest. 


(203)  Runout  face 

A  runout  face  is  a  subset  of  Face  (203).  The  subset  consists  of 
circular  faces  (205)  and  disk  faces  (211). 


(20r)  Planar  edge 

A  subset  of  Edge  (202).  Planar  edges  have  all  constituent  elements  in 
a  single  plane. 


(211)  Disk  face 

A  subset  Face  (203).  A  disk  face  refers  to  a  surface  perpendicular  to 
an  axis  of  symmetry  with  a  circular  boundary  (edge). 


i 
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(300)  Feature 


A  feature  is  a  referencable  geometric  subset  of  interest  in  a  model.  /' 
feature  is  also  a  class  of  entities: 


Class  of:  face  (203) 
edge  (202) 
vertex  (201) 
datum  (301) 
si2e_feature  (303) 
forni_feature  (304) 

End_class; 


(301)  Datum 

A  theoretically  exact  geometric  reference  to  which  toleranced  features 
are  related. 


Start_entity 

Referenced_entity  :  Topology  (200)  or  Feature_of 

_si2e  (306) 

name  :  String (2) 

End_entity? 

Attribute  Descriptions: 


Referenced_entity :  An  entity  which  serves  as  the 

exact  definition  of  the  datum. 


Name:  An  alphabetic  string  that  provides  a  unigue 
designation  for  the  datum  (ranee:  A..Z  AA..ZZ, 
excluding  I,  0,  and  Q) 


(302)  Conditioned  Datum 

A  conditioned  datum  is  a  datum  to  which  a  material  condition  specifi¬ 
cation  applies. 


Start_entity 

Base  :  Datum  (301) 

I'iaterial_condition  :  (!!,  Lr  S) 

End_entity ; 

Attribute  Descriptions: 

Base:  A  datum  entity  which  serves  as  the  exact 
definition  of  the  datum. 


Mater ial^condition :  An  enumerated  list  that  indicates 
the  material  condition  at  which  the  tolerance 
applies:  :•!  -  maximum  material  condition;  L  - 
least  material  condition;  or  S  -  regardless  of 
feature  sise. 
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least  material  condition;  or  S  -  regardless  of 
feature  size. 


(303)  Size  feature 


A  feature  whose  tolerancable  geometric  location  is  derived  from  physi¬ 
cal  feature  geometry  and  is  symmetric  about  a  point,  axis,  curve  or 
surface.  Size  tolerances  of  the  feature  are  independent  of  feature 
location.  This  entity  exists  to  allow  the  application  of  tolerances 
to  partially  modeled  or  incomplete  Features_of_size. 


Start_entity 

Tolerance_entity 

End_entity; 


Array  (2  to  maxint)  of 
face  (203) 


(304)  Form  feature 

A  referencable  geometric  subset  whose  name  implies  a  specific  physical 
configuration.  The  subset  does  not  include  the  size  feature  entities. 

Class  of:  Hole  (305) 

Feature_of_size  (305) 

End_class; 


(305)  Hole 

A  circular  opening,  of  possibly  stepped  or  graduated  dianeter,  into  or 
through  a  workpiece.  It  is  oriented  at  an  angle,  possibly  normal,  to 
the  surface  of  the  workpiece. 


(305)  Feature  of  size 

A  feature  of  size  is  a  subset  of  Form  feature  (304).  An  example  is  the 
Eole  (305). 
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Tolerance  Entities 


(400)  Tolerance 

The  allov;able  deviation  of  a  geonetric  aspect  of  a  product  from  its 
design  nominal  geometry. 

Class  of:  coordinate_tolerance  (401) 
geometric_tolerance  (402) 

End_class; 


(401)  Coordinate  tolerance 

A  coordinate  tolerance  is  a  class  of  entities: 

Class  of:  angle^tolerance  (404) 

location_tolerance  (403) 
size__tolerance  (405) 

End_class; 


(402)  Geometric  tolerance 

A  geometric  tolerance  is  a  class  of  entities; 

Class  of:  angularity  (406) 

circular^runout  (407) 
circularity  (408) 
concentricity  (409) 
cylindricity  (410) 
flatness  (411) 
parallelism  (412) 
perpendicularity  (413) 
position  (414) 
prof ile_of_a_line  (415) 
prof ile_of_a_surf ace  (416) 
straightness  (417) 
total^runout  (418) 


End_class; 
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Tolerance  Entities 


(403)  Location  tolerance 

Allov;able  deviation  of  measure  of  a  feature  from  its  design  nominal 
position  relative  to  a  specified  base  location  along  a  specified  path. 

Start_entity 

Origin  :  Location_origin  (503) 

Path  :  Location_path  (504) 

Toleranced_entity  :  Array  (1  to  maxint)  of 

Locat ion_toleranced_entity  (502) 
Basic  :  Boolean 

Plus_Tol  :  Real 

Hinus_Tol  :  Real 

End_entity; 

Attribute  Descriptions: 

Origin:  An  entity  that  serves  as  the  base  or  origin 

of  the  calculated  dimension.  It  is  the  "from" 
entity  of  the  directed  dimension. 

Path:  A  curve  along  which  (or  in  the  direction  of 
which)  the  dimension  is  measured. 

Toleranced_Entity :  An  array  of  entities  to  which 

the  tolerance  applies. 

Basic:  A  boolean  (true/false)  flag  that  indicates 
whether  the  entity  is  used  as  a  BA.^IC  dimen¬ 
sion. 

Plus^Tol:  The  absolute  value  of  the  tolerance  that  is 
added  to  the  nominal  dimension  value  to  esta¬ 
blish  the  maximum  allowable  deviation  of  the 
toleranced  entity  from  the  nominal. 

IIinus_Tol;  The  absolute  value  of  the  tolerance  that 
is  subtracted  from  the  nominal  dimension  value 
to  establish  the  minimum  allowable  deviation  of 
the  toleranced  entity  from  the  nom.inal. 
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(404)  Angle  tolerance 

Allowable  deviation  of  measure  of  a  toleranced  entity  from  its  design 
nominal  orientation  relative  to  a  specified  base  orientation. 

Start_entity 
Origin 

Toleranced_entity 

Basic 
Plus_Tol 
;:inus_Tol 
Sense 

End_entity; 

Attribute  Descriptions: 

Origin;  An  entity  that  serves  as  the  base  or  origin 
of  the  calculated  dimension.  It  is  the  "from" 
entity  of  the  directed  dimension. 

Toletanced_Entity;  An  array  of  entities  to  which  the 
tolerance  applies. 

Basic;  A  boolean  (true/false)  flag  that  indicates 
whether  the  entity  is  used  as  a  BASIC  dimen¬ 
sion  . 

Plus_Tol;  The  absolute  value  of  the  tolerance  that  is 
added  to  the  nominal  dimension  value  to  esta¬ 
blish  the  maximum  allowable  deviation  of  the 
toleranced  entity  from  the  nominal. 

Minus_Tol;  The  absolute  value  of  the  tolerance  that 
is  subtracted  from  the  nominal  dimension  value 
to  establish  the  minimum  allov/able  deviation  of 
the  toleranced  entity  from  the  nominal. 

Sense;  A  boolean  (true/false)  flag  which  indicates 
whether  or  not  the  angle  is  measured  in  a 
counter-clockwise  manner.  The  orientation  of 
measure  is  determined  by  the  cross-product  from 
the  origin  to  the  toleranced  entity  vector. 

If  the  cross-product  is  zero,  the  path  vector 
is  required  to  determine  the  orientation. 


;  Angle_origin  (501) 

;  Array  (1  to  maxint)  of 

Angle_toleranced_entity  (500) 
:  Boolean 
;  Real 
:  Real 
:  Boolean 
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(405)  Size  tolerance 

Allowable  deviation  of  measure  of  a  toleranced  entity  from  its  design 
nominal  magnitude^  e.g*  hole  diameter. 

Start_entity 
Tole  r anced_ent ity 

Basic 
Plus_Tol 
ninus_Tol 
End_entity; 

Attribute  Descriptions: 

Toleranced_Entity:  An  array  '  of  entities  to  which 

the  tolerance  applies. 

Basic:  A  boolean  (true/false)  flag  that  indicates 
whether  the  entity  is  used  as  a  BASIC  dimen¬ 
sion. 

Plus_Tol:  The  absolute  value  of  the  tolerance  that  is 
added  to  the  nominal  dimension  value  to  esta¬ 
blish  the  maximum  allowable  deviation  of  the 
toleranced  entity  from  the  nominal. 

Minus_Tol:  The  absolute  value  of  the  tolerance  that 
is  subtracted  from  the  nominal  dimension  value 
to  establish  the  minimum  allowable  deviation  of 
the  toleranced  entity  from  the  nominal. 


Array  (1  to  maxint)  of 
Size_toleranced_entity 
Booleanv^ 

Real  ^  |\ 

Real  . 


(505) 


12 


TOLERAnCE  IlODEL 


23  Oct  1985 


Tolerance  Entities 


(406)  Angularity 


Angularity  is  the  condition  of  a  surface  or  axis  at  a  specified  angle 
(other  than  90  degrees)  from  a  datum  plane  or  axis.  An  Angularity 
tolerance  specifies  a  tolerance  zone  defined  oy  two  parallel  planes  at 
the  specified  basic  angle  from  the  datum  plane  or  axis  within  v;hich 
the  surface  of  or  axis  of  the  considered  feature  must  lie. 

See  ANSI  ¥14.5:1  1982,  page  106,  section  6.6.2 
See  ISO  1101,  pages  18-19,  section  5.9 

Start_entity 

Toleranced_entity  :  Array  (1  to  maxint)  of 

Angular ity_t ole ranced_entity  (506) 


Tolerance 
Material_condition 
Projection 
Primary^datum 
Secondary_datum 
Tertiary_datum 
End_entity; 


Real 
(H,  L,  S) 

Optional  Point_vector  (102) 
Conditioned_datun  (302) 

Optional  Condi tioned_datur.;  (302) 
Optional  Conditioned_datun'.  (302) 


Attribute  Descriotions: 


Toleranced_Entity:  An  array 

the  tolerance  applies. 


of  entities  to  which 


Tolerance:  The  specified  allowable  deviation  from 

the  design  nominal  value. 

Material^condition:  An  enumerated  list  that  indicates 
the  material  condition  at  which  the  tolerance 
applies:  !*  -  maximum  material  condition;  L  - 
least  material  condition;  or  S  -  regardless  of 
feature  size. 


Projection:  A  point_vector  which  specifies  the 

additional  height  and  direction  of  the 
projected  tolerance  zone  outside  the  feature 
boundary. 

note:  Must  be  parallel  to  the  toleranced 

features.  Length  of  vector  determines  the 
extent  of  the  zone. 


Primary_datum:  A  conditioned_datum  entity  from  which 
the  dimension  is  measured.  This  primary  datu... 
is  the  most  important  datum  relative  to  the 
tolerance. 

Secondary^daturn:  A  conditioned_datum  entity  which  is 
the  second  most  important  datum  relative  to  the 
tolerance. 


Tertiary^datum:  A  conditioned^datum  entity  whicli 
third  most  important  datum  relative  to  the 
tolerance.  With  the  primary  and  secondary 


is  the 


data 
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it  establishes  a  datum  reference  frame  that  exactly 
locates  the  toleranced  feature. 
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(407)  Circular  runout 

Circular  runout  tolerance  defines  the  naxinuni  allowable  deviation  o 
position  of  a  coordinate  on  the  toleranceu  feature  during  one  complet 
revolution  of  that  feature  about  the  datum  axis,  without  relative 
axial  displacement  of  the  measuring  position.  Where  applied. to 
surfaces  constructed  around  a  datum  axis,  it  is  used  to  control  the 
cumulative  variations  of  circularity  amd  coaxiality.  Where  applied  to 
surfaces  constructed  at  right  angles  to  the  datum  axis,  circular 
runout  controls  circular  elements  of  a  plane  surface. 

See  AIISI  yi4.5M  1982,  page  109,  section  6.7.2. 1 
See  ISO  1101,  page  22-23,  section  5.12 

Start_entity 

Toleranced_entity  :  Array  (1  to  maxint)  of 

Circular_runout_toleranced_entity  (507 ) 
Tolerance  :  Real 

Primary_datum  :  Datum  (301) 

Co-primary_datum  :  Optional  Datum  (301) 

End_entity; 

Attribute  Descriptions: 

Toleranced_Entity:  An  array  of  entities  to  v:hich 

the  tolerance  applies. 

Tolerance;  The  specified  allowable  deviation  fro:., 
the  design  nominal  value, 

Pr imary_datum;  A  datum  entity  from  which 

the  dimension  is  measured.  This  primary  datun 
is  the  most  important  datum  relative  to  the 
tolerance. 

Co-pr imary_datum:  An  additional  datum  entity  which 
establishes  an  axis  with  the  primary  datum. 
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(408)  Circularity 

Circularity  is  a  condition  of  a  surface  of  revolution  such  that  all, 
points  of  the  surface  intersected  by  a  plane  perpendicular  to  the  axis 
or  center  ooint  are  equidistant  from  the  intersection  point  of  the 
plane  and  the  axis  or  center  point.  A  Circularity  tolerance  defines 
the  distance  between  two  concentric  circles  within  which  the 
coordinates  of  the  toleranced  feature  must  lie.  These  circles  are 
perpendicular  to  and  centered  on  the  axis  of  the  toleranced  feature. 
See  ANSI  Y14.5n  1982,  page  95,  section  6.4.3 
See  ISO  1101,  page  14,  section  5.3 

Start_entity 

Toleranced_ent ity  :  Array  (1  to  maxint)  of 

Circular ity_toleranceu_entity  (508) 

Tolerance  :  Real 

End_entity; 

Attribute  Descriptions: 

Toleranced_Entity;  An  array  of  entities  to  which 
the  tolerance  applies. 

Tolerance:  The  specified  allowable  deviation  from 

the  design  nominal  value. 


16 


TOLERANCE  IlODEL 


23  Oct  19S5 


Tolerance  Enticies 


(40?)  Concentricity 

A  Concentricity  tolerance  specifies  the  diameter  of  a  cylinder  cen¬ 
tered  on  a  datun  point  or  axis  within  which  the  center  or  axis  of  the 
toleranced  circular  or  cylindrical  feature  must  lie.  The  specified 
tolerance  and  datum  reference  apply  only  on  a  Regardless-of-Feature- 
Size  basis. 

See  ANSI  Y14.5M  1982,  page  84,  section  5.11.3 
See  ISO  1101,  page  21,  section  5.11.1 

Start^entity 

Toleranced_entity  :  Array  (1  to  maxint)  of 

Concentric ity_toleranced_entity  (509) 
Tolerance  :  Real 

Priniary_datum  i  Datum  (301) 

Co-primary_datun  :  Optional  Datum  (301) 

End_entity; 

Attribute  Descriptions: 

Toleranced_Entity :  An  array  of  entities  to  v;hich 

the  tolerance  applies. 

Tolerance:  The  specified  allovrable  deviation  from, 

the  design  nominal  value. 

Cylindrical_zone:  A  boolean  (true/false)  flag  that 

indicates  that  the  tolerance  value  is  the  dia¬ 
meter  of  a  cylindrical  zone  within  v.’hich  the 
axis  or  line  must  lie.  If  false,  the  zone  is 
parallelepipedic  or  the  space  between  t\.’o 
parallel  lines  or  planes. 

Primary_datum:  A  datura  entity  from  which 

the  dimension  is  measured.  This  primary  datum 
is  the  most  important  datum  relative  to  the 
tolerance. 

Co-primary_datum:  An  additional  datum  entity  which 
establishes  an  axis  with  the  primary  datum. 
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(410)  Cylindricity 

Cylindricity  tolerance  defines  the  distance  between  two  coaxial  cylin¬ 
ders  within  which  the  toleranced  cylindrical  feature  must  lie.  Unli..2 
circularity,  the  tolerance  applies  simultaneously  to  both  circular  anc 
longitudinal  elements  of  the  surface, 
see  ANSI  Y14.5M  1982,  page  96,  section  6.4.4 
See  ISO  1101,  page  14,  section  5.4 

Start_entity 

Toleranced  entity  :  Array  (1  to  roaxint)  of 

Cylindricity_tolerancea_entity  (510) 
Tolerance  :  Real 

End_entity; 

Attribute  Descriptions: 

Toleranced_Entity:  An  array  of  entities  to  which 

the  tolerance  applies. 

Tolerance;  The  specified  allowable  deviation  fro- 
the  design  nominal  value. 
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(411)  Flatness 

Flatness  tolerance  defines  distance  oetween  two  parallel  planes 
between  which  the  toleranced  surface  must  lie.  The  tolerance  may  he 
applied  on  a  unit  basis  as  a  means  of  preventing  abrupt  surface 
variation  within  a  small  area  of  the  feature. 

See  ANSI  yi4.5n  1982,  page  94,  section  6.4.2 
See  ISO  1101,  page  13,  section  5.2 

Start_entity 

Toleranced^entity  :  Array  (1  to  maxint)  of 

Flatness^toleranced^entity  (511) 
Tolerance  :  Real 

I*aterial_condition  :  (II,  L,  S) 

Per_unit_square  i  Optional  Real 

End^entity; 

Attribute  Descriptions: 

Toleranced_Ent ity:  An  array  of  entities  to  v;hich 

the  tolerance  applies. 

Tolerance:  The  specified  allov/able  deviation  from 

the  design  nominal  value. 

Material_condition:  An  enumerated  list  that  indicates 
the  material  condition  at  which  the  tolerance 
applies:  M  -  maximum  material  condition;  L  - 
least  material  condition;  or  S  -  regardless  of 
feature  size. 

Per_unit_square:  Specifies  the  side  of  any  square 
region  on  the  toleranced_entity  over  which 
the  tolerance  value  applies.  Used  to  prevent 
abrupt  surface  variation  in  a  relatively  small 
area  of  the  feature. 
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(412)  Parallelism 


Parallelism  is  the  condition  of  a  surface  equidistant  at  all  ooints 
from  a  datum  plane  or  an  axis  equidistant  along  its  length  from  a| 
datum  axis.  A  Parallelism  tolerance  specifies  the  distance  between  two 
planes  or  lines  parallel  to  a  datum  plane^  or  axis#  within  which  the 
line  elements  of  the  surface  or  axis  of  the  considered  feature  must 
lie»  or  a  cylindrical  tolerance  zone  whose  axis  is  parallel  to  the 
datum  axis,  within  which  the  axis  of  the  considered  feature  must  lie. 
The  allowable  feature  position  zone  may  be  cylindrical (fig  45),  oaral- 
lelepipedic  (fig  51)  or  planar  (fig  47,54)  for  line  features  and  is 
similar  to  a  flatness  tolerance  zone  for  surface  features  (fig  57,60). 
These  figure  references  are  to  the  ISO  1101  standard. 

See  ANSI  Y14.5M  1982,  page  106,  section  6.6.3 
See  ISO  1101,  page  15-17,  section  5.7 


Start_entity 
Toleranced_entity 


Array  (1  to  maxint)  of 


Tolerance 
i:aterial_condition 
Cylindrical_zone 
Projection 
Primary_datuir. 
Enu.entity; 

Attribute  Descriptions: 


Parallelisn_tolerancecl_entity  (512) 
:  Real 

(M/  L,  S) 

Boolean 

Optional  Point_vector  (102) 
Conditioned_datum  (302) 


Toleranced^Ent'ity:  An  array 

the  tolerance  applies. 


of  entities  to  which 


Tolerance:  The  specified  allowable  deviation  fro.-. 

the  design  nominal  value. 


Material^condition:  Aji  enumerated  list  that  indicates 
the  material  condition  at  which  the  tolerance 
applies:  M  -  maximum  material  condition;  L  - 
least  material  condition;  or  S  -  regardless  of 
feature  size. 


Cylindrical_zone:  A  boolean  (true/false)  flag  that 

indicates  that  the  tolerance  value  is  the  dia¬ 
meter  of  a  cylindrical  zone  within  which  the 
axis  or  line  must  lie.  If  false,  the  zone  is 
parallelepipedic  or  the  space  between  two 
parallel  lines  or  planes. 


Projection;  A  pointy vector  which  specifies 
additional  height  and  direction  of 
projected  tolerance  zone  outside  the  feature 
boundary. 

Note:  Must  be  parallel  to  the  toleranced 

features.  Length  of  vector  determines 
extent  of  the  zone. 


the 

the 


-  20  - 


TOLERANCE  MODEL 


23  Oct  1985 


Tolerance  Entities 


Pr iinary_datuiii:  A  conditioned^datuin  entity  from  which 
the  dimension  is  measured. 


(413)  Perpendicularity 

Perpendicularity  tolerance  defines  the  allov/able  linear  deviation  fron 
a  true  right  angle  of  line  or  surface  features  with  respect  to  line  or 
surface  datums.  Several  interpretations  of  the  exact  tolerance  cone 
are  possible  for  line  feature  with  respect  to  surface  datums.  See 
figures  65,67  and  69  in  ISO  1101, page  17. 

See  ANSI  Y14.5M  1982,  page  105,  section  6.S.4 
See  ISO  1101,  page  17-18,  section  5.8 

Start_entity 

Toleranced_entity  :  Array  (1  to  maxint)  of 

Perpendicular ity_toleranced_entity  (513) 
Tolerance  :  Real 

Haterial_condition  :  (M,  L,  S) 

Cylindrical_2one  :  Boolean 

Projection  :  Optional  Point_vector  (102) 

Primary_datum  :  Conditioned_datum  (302) 

Secondary_datum  :  Optional  Condi tioned_da turn  (302) 

End_entity; 

Attribute  Descriptions: 

Toleranced_Entity:  An  array  of  entities  to  which 

the  tolerance  applies. 

Tolerance:  The  specified  allov/able  deviation  fron 

the  design  nominal  value. 

Haterial_condition;  An  enumerated  list  that  indicates 
the  material  condition  at  which  the  tolerance 
applies:  M  -  maximum  material  condition;  L  - 
least  material  condition;  or  S  -  regardless  of 
feature  size. 

Cylindrical_zone:  A  boolean  (true/false)  flag  that 

indicates  that  the  tolerance  value  is  the  dia¬ 
meter  of  a  cylindrical  zone  within  which  the 
axis  or  line  must  lie.  If  false,  the  zone  is 
parallelepipedic  or  the  space  between  two 
parallel  lines  or  planes. 

Projection;  A  point_vector  which  specifies  the 
additional  height  and  direction  of  the 
projected  tolerance  zone  outside  the  feature 
boundary. 

Note:  Must  be  parallel  to  the  toleranced 

features.  Length  of  vector  determines  the 
extent  of  the  zone. 
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Prinary^datum:  A  conditioned_datuni  entity  frow  which 
the  dimension  is  measured.  This  primary  datum 
is  the  most  important  datum  relative  to  the 
tolerance. 

Secondary_datum:  A  conditioned_datum  entity  which  is 
the  second  most  important  datum  relative  to  the 
tolerance. 


(414)  Position 


Position  tolerance  defines  the  allowable  deviation  of  position  of  the 
center  pointr  axis,  or  center  plane  of  a  feature  of  size.  A  center 
point  tolerance  defines  the  diameter  of  a  spherical  or  circular  zone, 
an  axis  tolerance  defines  the  measure  of  a  cylindrical,  parallelepi- 
pedic  or  planar  zone  and  a  center  plane  tolerance  defines  a  zone 
specified  by  the  distance  between  two  bounding  parallel  planes.  Each 
zone  is  considered  to  contain  the  true  position  of  the  toleranced 
feature. 

See  ANSI  Y14.5ri  1982,  page  53-89,  section  5.2 
See  ISC  1101,  page  19-20,  section  5.10 


Start_entity 

Toleranced^entity 

Tolerance 

Material^condition 

Cy 1 ind  r ical_zone 

Projection 

Primary_datun 

Secondary_datum 

Tertiary^datum 

End_entity; 


:  Array  (1  to  maxint)  of 
Positioh_toleranced_ent ity  (514) 
:  Real 


(Mr  L,  S) 

Boolean 

Optional  Point^vector  (102) 
Conditioned^datum  (302) 
Optional  Conditionec_datum 
Optional  Conditioned_datum 


(30 

(30 


Attribute  Descriptions: 


Toleranced^Entity;  An  array  of  entities  to  which 
the  tolerance  applies. 


Tolerance:  The  specified  allov/able  deviation  from 

the  design  nominal  value. 


Material.condition:  An  enumerated  list  that  indicates 
the  material  condition  at  which  the  tolerance 
applies:  M  -  maximum  material  condition;  L  - 
least  material  condition;  or  S  -  regardless  of 
feature  size. 


Cylindrical_zone:  A  boolean  (true/false)  flag  that 

indicates  that  the  tolerance  value  is  the  dia¬ 
meter  of  a  cylindrical  zone  within  which  the 
axis  or  line  must  lie.  If  false,  the  zone  is 
parallelepipedic  or  the  space  between  two 
parallel  lines  or  planes. 
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Projection;  A  point_vector  which  specifies  the 
adoitional  height  and  direction  of  the 
projected  tolerance  zone  outside  the  feature 
boundary.  Note;  The  length  of  the  vector 
determines  the  length  of  the  zone. 

Pr imary_detum;  A  conditioned_datum  entity  from  which 
the  dimension  is  measured.  This  primary  datum 
is  the  most  important  datum  relative  to  the 
tolerance. 

Secondary_datum;  A  conditioned_datum  entity  which  is 
the  second  most  important  datum  relative  to  the 
tolerance. 

Tertiary_datum;  A  conditioned_datum  entity  v/hich  is  the 
third  most  important  datum  relative  to  the 
tolerance.  With  the  primary  and  secondary  data, 
it  establishes  a  datum  reference  frame  that  exactly 
locates  the  toleranced  feature. 
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(415)  Profile  of  a  line 


Profile  of  a  line  tolerance  specifies  the  diameter  of  a  circle  which, 
when  its  center,  or  one  tangent,  moves  along  the  design  nominal  curve 
feature,  sweeps  the  region  in  which  the  feature  must  lie.  The 
tolerance  is  two-dimensional  and  applies  normal  (perpendicular)  to  the 
true  profile  at  all  points,  inhere  a  sharp  corner  is  included,  the 
tolerance  zone  extends  to  the  intersection  of  the  boundary  lines. 

See  AIISI  yi4.5M  1962,  page  57-104,  section  6.5.1 
See  ISO  1101,  page  14,  section  5.5 


Start_entity 

Toleranced_entity  :  Array  (1  to  roaxint)  of 
Prof ile_of_a_line_toleranced_entity 


Directrix 
Tolerance 
Application 
Primary^datum 
Secondary_datuin 
Tertiary_datuir. 
End_entity; 


(515) 


Optional 

Real 

(I»3,0) 

Optional 

Optional 

Optional 


unit  vector  (101) 


Condit ioned_d£tum  (302) 
Conditioned_datum  (302) 
Condit ioned_datur.  (302) 


Attribute  Descriptions: 


Toleranced_Entity;  An  array  of  entities  to  which 
the  tolerance  applies. 


Tolerance:  The  specified  allowable  deviation 

the  design  nominal  value. 


from 


Application:  An  enumerated  list  that  specifies  the 
tolerance  application  to  be  I-inside, 
B-bilateral,  or  0-outside. 


Pr imary_datum:  A  conditioned_datum  entity  from  v/hich 
the  dimension  is  measured.  This  primary  datum 
is  the  most  important  datum  relative  to  the 
tolerance.  Required  only  when  a  unique  plane 
cannot  be  calculated  from  the  toleranced_entity . 

Secondary_datum:  A  conditioned_datum  entity  v;hich  is 
the  second  most  important  datum  relative  to  the 
tolerance. 


Tertiary_datum:  A  conditioned_datum  entity  which  is  the 
third  most  important  datum  relative  to  the 
tolerance.  With  the  primary  and  secondary  data, 
it  establishes  a  datum  reference  frame  that  exactly 
locates  the  toleranced  feature. 


Directrix:  Cross  sections  of  the  toleranced  face  taken 

planes  normal  to  the  directrix  establish  the  line 
profile  that  is  toleranced.  The  directrix  is 
required  only  if  a  datum  is  not  included  in  the 
line  tolerance  entity. 


in 
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(416)  Profile  of  a  surface 

A  profile  of  a  surface  tolerance  specifies  the  distance  between  twc 
"ball-offset"  surfaces  located  on  equally  on  either  side,  or  totally 
on  one  side,  of  the  design  nominal  feature.  The  toleranced  feature 
must  lie  between  these  surfaces.  The  tolerance  is  three-dimensional 
and  applies  normal  (perpendicular)  to  the  true  profile  at  all  points. 
Where  a  sharp  corner  is  included,  the  tolerance  zone  extends  to  the 
intersection  of  the  boundary. 

See  AMSI  yi4.5M  1982,  page  97-104,  section  6.5.1 
See  ISO  1101,  page  14,  section  5.5 

Start_entity 

Toleranced_entity  :  Array  (1  to  maxint)  of 

Profile_of_a_surf ace_toleranced_entity  (516) 
Tolerance  :  Real 

Application  ;  (I,B,0) 

Ptimary_datum  :  Optional  Conditioned_datum  (302) 

Secondaty_datum  :  Optional  Conditionec_datu~,  (302) 

Tertiary_datum  ;  Optional  ConditiQned_Qatur.;  (302) 

End^entity; 

Attribute  Descriptions: 

Toleranced_Entity:  An  array  of  entities  to  which 

the  tolerance  applies. 

Tolerance:  The  specified  allowable  deviation  from 

the  design  nominal  value. 

Application:  An  enumerated  list  that  specifies  the 
tolerance  application  to  be  I-inside, 

B-bilateral,  or  0-outside. 

Primaty_datum;  A  conditioned_datum  entity  from  which 
the  dimension  is  measured.  This  primary  datur^ 
is  the  most  important  datum  relative  to  the 
tolerance. 

Secondary_datum:  A  conditioned_datum  entity  which  is 
the  second  most  important  datum  relative  to  the 
tolerance. 

Tertiary_datum:  A  conditioned_datum  entity  which  is  the 
third  most  important  datum  relative  to  the 
tolerance.  Viith  the  primary  and  secondary  data, 
it  establishes  a  datum  reference  frame  that  exactly 
locates  the  toleranced  feature. 
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(417)  Straightness 

Straightness  tolerance  defines  the  allowable  deviation  of  a  line  or  of 
line  elements  of  a  surface  feature.  The  tolerance  zones  for  line 
features  are  cylindrical,  parallelepipedic  and  parallel  planes. 
Straightness  tolerance  for  surface  features  specify  the  distance 
between  two  parallel  lines  within  which  a  linear  element  of  the  sur¬ 
face,  in  a  specified  direction,  must  lie.  The  linear  element  is  a 
cross  section  of  the  surface  in  a  plane  parallel  to  the  direction 
vector  and  normal  to  the  surface.  See  figures  27, 2S  and  31  in  the  ISO 
1101  standard,  page  17. 

See  ANSI  yi4.5H  1982,  page  91-94,  section  6.4.1 
See  ISO  1101,  page  13,  section  5.1 


Start_entity 

Toleranced_entity  :  Array  (1  to  nazint)  of 

Straightness_toleranced_entity  (517) 


Direction 
Tolerance 

Material_condition 

Cylindrical_2one 

Per_unit_length 

End_entity; 


Optional  Unit_vector  (ICl) 
Real 

(M,  L,  S) 

Boolean 
Real 


Attribute  Descriptions: 

Toleranced_Entity:  An  array  of  entities  to  which 

the  tolerance  applies. 


Direction:  A  unit  vector  that  specifies  the 

straightness  tolerance  for  linear  surface 
elements.  Required  v;hen  the  toleranced_entity 
is  a  surface.  It  must  be  parallel  to  the  surface. 


Tolerance:  The  specified  allowable  deviation  fron. 

the  design  nominal  value. 

Material^condition:  An  enumerated  list  that  indicates 
the  material  condition  at  which  the  tolerance 
applies:  11  -  maximum  material  condition;  L  - 
least  material  condition;  or  S  -  regardless  of 
feature  size. 

Cylindrical_zone:  A  boolean  (true/false)  flag  that 

indicates  that  the  tolerance  value  is  the  dia¬ 
meter  of  a  cylindrical  zone  within  which  the 
axis  or  line  must  lie.  If  false,  the  zone  is 
parallelepipedic  or  the  space  between  two 
parallel  lines  or  planes. 


Per_unit_length:  Specifies  the  linear  distance 

within  which  the  tolerance  value  applies.  Used  to 
prevent  abrupt  chances  in  the  direction  of  the 
toleranced  entity. 
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(41G)  Total  runout 

A  total  runout  tolerance  specifies  the  maximum  allowable  deviation  of 
position  for  all  points  on  the  toleranced  feature  during  one  complete 
revolution  of  the  feature  about  the  datum  axiSr  with  relative  axial 
displacement  of  the  measuring  position.  Where  applied  to  surfaces 
constructed  around  a  datum  axis,  it  is  used  to  control  the  cumulative 
variations  of  circularity,  straightness,  angularity,  taper,  profile  o 
a  surface,  and  coaxiality,  where  applied  to  surfaces  constructed  a 
tight  angles  to  the  datum  axis,  total  runout  controls  perpendicularity 
and  flatness. 

See  ANSI  yl4.5M  1982,  page  109,  section  6. 7. 2. 2 
See  ISO  1101,  page  22-23,  section  5.12 

Note  that  ANSI  and  ISO  do  not  explicitly  define  total  runout  for  , 
non-cyl indr ical  surfaces.  It  is  assumed  that  this  is  due  to 
mechanical  measurement  limitations. 

Start_entity 

Toleranced_entity  :  Array  (1  to  naxint)  of 

Total_runout_toleranced_entity  (513) 
Tolerance  :  Real 

Pr imary_datum  :  Datum  (301) 

Co-primary_datuffi  :  Optional  Datum  (301) 

End_entity; 

Attribute  Descriptions: 

Toleranced_Entity:  An  array  of  entities  to  v/hich 

the  tolerance  applies. 

Tolerance:  The  specified  allov/able  deviation  f roi: 

the  design  nominal  value. 

Pr imary_datum:  A  datum  entity  from  which 

the  dimension  is  measured.  This  primary  datum 
is  the  most  important  datum  relative  to  the 
tolerance. 


Co-primary_datum:  An  additional  datum  entity  which 
establishes  an  axis  with  the  primary  datum. 
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(500)  Angle  toleranced  entity 

Angle  toleranced  entity  is  a  point  vector  and  a  memder  from  the  class 
edge  (202) r  planar  face  (206)  and  size  feature  (303). 


Start^entity 

Toleranced_entity 

Plane  of  measure 
Toleranced_location 

End_entity; 


Face  (203) r  edge  (202), 
si2e_feature  (303) 
Unit_vector  (101) 

Array  of  1:N  of  Point_vector 
(102) 


Attribute  Descriptions: 

Toleranced_Entity:  An  entity  to  which  the  tolerance 
applies. 


Plane  of  measure:  Unit  vector  which  specifies  the 
normal  to  the  plane  in  which  the  angle  is 
measured. 

Note:  The  path  vector  must  be  normal  to  the 
ang-tol-ents (500)  point  vector  anu  the 
ang-org(501)  vector.  The  path  must  exist 
vector(500)  and  the  vector(501)  do  not 
define  a  unique  plane. 

Toleranced_location:  A  point^vector  which  specifies 
the  reference  orientation  on  the  toleranced 
entity.  It  must  lie  on  the  toleranced  entity. 
Multiple  point_vectors  apply  to  ruled  surface 
toleranced_entities. 


(501)  Angle  origin 


Angle  origin  entity  is  an  origin  vector  and  a  member  of  the  class  ecce 
(202),  face  (203)  or  datum  (301). 


Start_entity 

Origin_entity 

Or igin_vectot 
End_entity; 

Attribute  Descriptions: 


:  Face  (203)  r  edge  (202)/  or 
datum  (301) 

:  Unit_vector  (101) 


Origin_entity:  A  face,  edge,  or  datum  that  serves  as 
the  base  of  the  calculated  dimension.  It  is 
the  "from"  entity  of  the  directed  dimension. 


Or igin_vector :  A  unit_vector  which  specifies  the 
base  orientation.  The  origin  vector  must  be 
contained  in  the  origin  entity  and  at  the 
location  of  the  toleranced  entity. 
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(502) 


Location  toleranced  entity 


Location  toleranced  entity  is  a  location  coordinate  and  a  member  from 
the  class  of  edge  (202),  face  (203),  location  tolerance  qualified  form 
feature  (533),  size  feature  (303),  vertex  (201). 


Start_entity 

Toleranced_entity  ;  Face,  edge,  vertex, 

si2e_feeture,  or 
location_tolerance_ 
qualif ied_f orm_feature 
Toleranced_location  :  Coordinate  (107) 
End_entity; 

Attribute  Descriptions: 

Toleranced_Entity:  An  entity  to  which  tha  tolerance 
applies. 


Toleranced_location:  A  coordinate  which  specifies 

the  reference  location  on  the  toleranced  entity. 
The  coordinate  must  lie  on  the  toleranced  entity. 


(5C3)  Location  origin 


Location  origin 
edge  (202),  face 


is  an  origin 
(203),  datum 


coordinate 
(301) ,  vertex 


and 


a  member 
f201). 


from  the  class 


Start_entity 

Or igin_entity  :  Face,  edge,  vertex,  or 

datum 

Origin_location  ;  Coordinate  (107) 

End^entity; 

Attribute  Descriptions: 

Origin_entity :  An  entity  that  serves  as  the  base  of 
the  calculated  dimension.  It  is  the  "fron” 
entity  of  the  directed  dimension. 

Origin_locat ion:  A  coordinate  which  specifies  the  base 
position.  The  coordinate  must  lie  on  the  origin 
entity. 
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(504)  Location  path 

A  location  path  is  a  class  o£  entities: 

Class  of:  unit_vector  (101) 
curve  (105) 

End.class; 

It  is  used  to  specify  the  path  along  \7hich  a  dimension  measure  is 
calculated.  A  curve  instance  must  contain  but  not  necessarily  end  with 
the  toleranced  coordinate  point(s). 


(505)  Size  toleranced  entity 

Size  toleranced  entity  is  a  class  of  entities: 


Class  of:  size_feature  (303) 
circular  edge  (20v) 
cylindrical  face  (205) 
size_tolerance_ 

qualif  ied_f  orir_feature 


EnQ_class; 


(519) 


Each  of  these  entities  has  a  symmetric  set  of  geometric  entities  which 
is  toleranced  as  to  size  of  the  syrumetric  elements. 


(506)  Angularity  toleranced  entity 

Angularity  toleranced  entity  is  a  class  of  entities; 


Class  of:  face  (203) 
edge  (202) 
size.feature  (303) 
angular ity_tolerance_ 

qualif ied_f orm_feature 


End_class; 


(52-:) 


(507)  Circular  runout  toleranced  entity 

Circular  runout  toleranced  entity  is  a  class  of  entities: 


Class  of:  circular  edge  (204) 
runout^face  (208) 
circular_runout_tolerance_ 

qualif ied_form_f eat u 


End_class; 


re 


(52?) 
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(508)  Circularity  toleranced  entity 

Circularity  toleranced  entity  is  a  class  o£  entities: 


Class  of: 


End_class; 


circular_face  (205) 
circular.edge  (204) 
circularity_tolerance_ 

qualified_f  orni_feature 


(524) 


(509)  Concentricity  toleranced  entity 

Concentricity  toleranced  entity  is  a  class  of  entities: 


Class  of: 


End^class 


circular_face  (205) 
circular_edge  (204) 
concent ricity_t ole tance_ 

qualif  ied_f  orni_feature 


(521) 


(510)  Cylindricity  toleranced  entity 


Cylindricity  toleranced  entity  is  a  class  of  entities: 


Class  of: 


End_class 


cylindrical_face  (207) 
cylindricity_tolerance_ 

qualif ied_f orn_feeture 


(525) 


(511)  Flatness  toleranced  entity 

Flatness  toleranced  entity  is  a  class  of  entities: 


Class  of: 


End_class; 


planar_face  (206) 
flatness_toletance_ 

qualif ied_form_feature 


(522) 


(512)  Parallelisivi  toleranced  entity 

Parallelism  toleranced  entity  is  a  class  of  entities: 

Class  of:  face  (203) 
edge  (202) 
size^feature  (303) 
parallelism_tolerance_ 

qualif ied_f orm_feature  (527) 

End_class; 
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(513)  Perpendicularity  toleranced  entity 


Perpendicularity  toleranced  entity  is  a  class  of  entities: 


Class  of:  face  (203) 
edge  (202) 
size_feature  (303) 
perpendicularity_tolerance_ 

qualif  ied_forra_feature 


End.class; 


(526) 


(514)  Position  toleranced  entity 

Position  toleranced  entity  is  a  class  of  entities: 


Class  of:  size_feature  (303) 
position_tolerance_ 

qualif ied_f oriii_feature  (52C) 

End.class; 


(515)  Prof ile-of-a-line  toleranced  entity 


Profile  of  a  line  toleranced  entity  is  a  class  of  entities: 


Class  of:  face  (203) 

planar_edge  (209) 

prof ile_of_a_line_tolerance_ 

qualif ied_f orm.feature 


End.class; 


(531) 


(516)  Prof ile-of-a-surface  toleranced  entity 

Profile  of  a  surface  toleranced  entity  is  a  class  of  entities: 


Class  of:  face  (203) 

prof ile_of_a_surface_tolerance_ 

qualified_f orr^feature 


End.class; 


(532) 


(517)  Straightness  toleranced  entity 

Straightness  toleranced  entity  is  a  class  of  entities: 

Class  of:  face  (203) 
edge  (202) 
size.feature  (303) 
straightness_tolerance_ 

qualif ied_form_feature  (523) 


End.class; 


TOLSRANCE  ilODEL 


23  Oct  1985 


Miscellaneous  Entities 


(518)  Total  runout  toleranced  entity 

Total  runout  toleranced  entity  is  a  class  of  entities: 


Class  of:  runout_face  (208) 

total_runout_tolerance_ 

qualif  ied_forin_feature 


End_class; 


(530) 


(519)  Size  tolerance  qualified  form  feature 

Size  tolerance  qualified  form  feature  is  a  class  of  entities: 

Class  of:  Hole  (305) 

End_class; 

(520)  Position  tolerance  qualified  form  feature 

Position  tolerance  qualified  form  feature  is  a  class  of  entities: 

Class  of:  Hole  (305) 

End_class; 

(521)  Concentricity  tolerance  qualified  form  feature 

Concentricity  tolerance  qualified  form  feature  is  a  class  of  entities: 

Class  of:  Hole  (305) 

End.class; 

(522)  Flatness  tolerance  qualified  form  feature 

A  flatness  tolerance  qualified  form  feature  is  a  class  of  entities 
which  exhibit  the  properties  of  a  plane  in  the  region  of  interest. 

Class  of:  <null> 

End_class; 

(523)  Straightness  tolerance  qualified  form  feature 

Straightness  tolerance  qualified  form  feature  is  a  class  of  entities: 


Class  of:  Hole  (305) 
End^class; 
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(524)  Circularity  tolerance  qualified  form  feature 

Circularity  tolerance  qualified  form  feature  is  a  class  of  entities: 

Class  of:  Hole  (305) 

End.class; 

(525)  Cylindricity  tolerance  qualified  form  feature 

Cylindricity  tolerance  qualified  form  feature  is  a  class  of  entities: 

Class  of:  Hole  (305) 

End_class; 

(526)  Perpendicularity  tolerance  qualified  form  feature 

Perpendicularity  tolerance  qualified  form  feature  is  a  class  of 
entities: 

Class  of:  Hole  (305) 

Cnd_class; 

(527)  Parallelism  tolerance  qualified  form  feature 

Parallelism  tolerance  qualified  form  feature  is  a  class  of  entities; 

Class  of:  Hole  (305) 

End.class; 

(528)  Angularity  tolerance  qualified  form  feature 

Angularity  tolerance  qualified  form  feature  is  a  class  of  entities: 

Class  of:  Hole  (305) 

End.class; 

(529)  Circular  runout  tolerance  qualified  form  feature 

Circular  runout  tolerance  qualified  form  feature  is  a  class  of 
entities: 

Class  of:  Hole  (305) 

End_class; 

(530)  Total  runout  tolerance  qualified  form  feature 

Total  runout  tolerance  qualified  form  features  is  a  class  of  entities: 

I 

Class  of:  Hole  (305) 

End_class; 
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(531)  Profile  of  a  line  tolerance  qualified  form  feature 

Profile  of  a  line  tolerance  qualified  form  features  is  a  class  of 
entities: 

Class  of:  <null> 

End_class7 

(532)  Profile  of  a  surface  tolerance  qualified  form  feature 

Profile  of  a  surface  tolerance  qualified  form  features  is  a  class  of 
entities: 

Class  of:  <null> 

End_class; 

(533)  Location  tolerance  qualified  form  feature 

Location  tolerance  qualified  form  features  is  a  class  of  entities: 

Class  of:  Hole  (305) 

End_class; 
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This  model  should  be  interpreted  as  an  IDEFl  model  with  the 
following  conventions  and  assumptions: 


1.  An  arc  is  used  below  or  above  the  subject  entity  through  a  number  of 
it's  relationships  to  denote  an  exclusive-or.  This  means  that  only 
one  relationship  of  those  thorugh  which  the  arc  passes  can  exist  for 
a  given  instance  of  the  subject  entity. 

2.  An  unlabeled  relationship  that  has  parentheses  on  it  near  the 
independant  entity  denotes  an  "equivalence"  relationship  that  is 
read  '|can  be/is."  This  relationship  exists  primarily  between  class 
entities  and  the  members  of  the  class. 

3.  On  "diamond"  relationships  a  range  indicator  of  the  form  N;M  is 
placed  beside  the  diamond.  This  indicates  the  minimum  and  maximum 
number  of  entities  which  can  be  referenced  in  the  relationship. 

4.  There  is  a  distinction  made  between  two  types  of  relationships  and 
two  types  of  entities.  The  two  types  of  relationships  are  the 
typical  IDEFl  relationship  with  a  verb-liJce  label  and  the 
relationship  described  in  item  3.  The  two  types  of  entities  are 
"class"  entities  and  the  typical  IDEFl  entities  Which  have 
attributes.  Class  entities  have  no  attributes  and  are  used  to  group 
entities  that  are  similar  in  nature. 

D An  asterisk  that  is  used  in  place  of  an  entity  number  indicates  that 
the  definition  of  that  entity  is  outside  the  scope  of  the  model. 

The  entity,  in  this  case,  serves  as  a  link  to  other  models. 
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PDES  SCHEMA 


-  START  OF  TOLERANCING  ENTITIES 

-  VERSION  0.1 

-  AUTHOR  COLSHURE/ BURKETT 

LASS  tolerancing  OF 


(datum,,  tolerance); 


CLASS  datum  OF 

(coordinate_toler_datum,  geometric_tol er_datum) ; 

CLASS  coordinate_toler_datum  OF 

(angle_toler_datum,  location_toler_datum) ; 


CLASS  geometri c_tol er_datum  OF 

(angular i ty_toler_datum,  circular_runout_toler_datum, 
concentrici ty_toler_datum ,  paral lei ism_tol er_datum , 
per pend i cul ari ty_tol er_datum,  posit i on_tol er_datum , 
pro-f i  1  e_l  i  ne_tol  er_datum ,  pro-f  i  1  e_surf ace^tol  er_datum , 
total ^runout_tol er_datum)  ; 


CLASS  tolerance  OF 

(coordinate_tol er ,  geometric_toler ) ; 


ASS  coordinate 
(angl e_tol er , 


_toler  OF 
location_toler , 


si2e_toler) ; 


CLASS  geometri c_tol er  OF 

( angul ar i ty_tol er ,  ci rcul dr_runout _tol er ,  circularity_tol er , 
concentrici  ty_toler  ,  cyl  i ndr i ci ty_tol er  ,  -f  1  atness_tol er  , 
paral 1  el i sm_tol er ,  perpendi cul ari ty_tol er ,  posi ti on_tol er , 
pro-f  i  le_l  ine_toler  ,  pro-f  i  le^sur-f  ace_toler  ,  strai  ghtness_tol  er  , 
total _runout_tol er ) ; 


CLASS  angl e_tol er_datum  OF 

(-face,  edge,  -f eature-o-f-si r e)  ; 


ENTITY  1 ocat i on_tol er_datum; 
NOROLE 

name  :  STRING; 

ROLE 

END; 


15 


PDES  SCHEMA 


ENTITY  angul ari ty_toler_datum; 
NOROLE 

name  :  STRING; 

ROLE 

END; 


ENTITY  circul ar_runout_toler_datum; 
NOROLE 

name  :  STRING; 

ROLE 

END; 


ENTITY  concentric! ty_toler_datum; 
NOROLE 

name  :  STRING; 

ROLE 

END; 


ENTITY  paral  1  el  i  sm_tol  er_datLim; 
NOROLE 

name  :  STRING; 

ROLE 

END; 


ENTITY  per pend i cul ari ty_tol er_datum; 
NOROLE 

name  :  STRING; 

ROLE 

END; 


ENTITY  posi t i on_tol er_datum; 
NOROLE 

name  :  STRING; 

ROLE 

END; 


ENTITY  pro-f  1 1  e_l  i ne_tol er_datum; 
NOROLE 

name  :  STRING; 

ROLE 

END; 


ENTITY  pro-f  i  le_sur-f  ace_toler_datum; 
NOROLE 

name  ;  STRING; 

ROLE 

END; 
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ENTITY  total _runout  toler_datum; 
NOROLE 


STRING; 


ENTITY  angle_toler; 

NOROLE 

name  t  STRING; 

ROLE 

applies  ;  LIST<1  to  *  )  OF  REFER (angle_toler_ob ject) ; 
toler_value  :  list<l  to  2>  o-f  t_magnitude; 
primary_datum  :  re-fer  <angle_toler_datum)  ; 
angle_direction  :  logical; 

END; 


ENTITY  location_toler ; 

NOROLE 

name  :  STRING; 

ROLE 

applies  ;  LISTd  to  *  )  OF  REFER  <)  ; 
toler_value  :  t_magnitude; 

END; 


entity  1 ocati on_tol er ; 


NTITY 

OROLE 


name 

ROLE 


size_toler; 
:  STRING; 


tolval  :  listd  to  2)  o-f  t_magnitude; 
appies  :  LIST(1  to  *  )  OF  REFER (size  toler  object); 
END; 


ENTITY  angul ari ty_toler ; 

NQROLE 

name  :  STRING; 

ROLE 

applies  :  LIST d  to  *  )  OF  REFER (angul ari ty_toler_ob ject > 
toler_value  :  t_magnitude; 

pri mary_datum  :  re-fer  (angularity_toler_datum)  ; 
secondary_datum  :  OPTIONAL  re-fer  (angularity_toler_datum)  ; 
tert i ary_datum  :  re-fer  (angulari ty_toler_datum) ; 
projected  toler  zone  :  re-fer  (1  ine)  ; 

END; 
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ENTITY  circular_runout_toler ; 

NOROLE 

name  :  STRING; 

ROLE 

applies  :  LISTd  to  *  )  OF  REFER (circul ar_runout_tol er^object ) 
toler_value  :  t_magnitude; 

primary_datum  :  re-fer  (circular_runout_toler_datum>  ; 
secondary_datum  :  OPTIONAL  refer (circular  runout  tol er^datum) ; 
END; 


ENTITY  circularity  toler; 

NOROLE 

name  :  STRING; 

ROLE 

applies  :  LISTd  to  *  )  OF  REFER (circul ari ty_tol er_object ) ; 
toler_value  :  t  magnitude; 

END; 


ENTITY  concentricity_toler ; 

NOROLE 

name  :  STRING; 

ROLE 

applies  :  LISTd  to  ♦  )  OF  REFER (concentri ci ty_tol er_object ) ; 
toler^value  :  t^magnitude; 

pr i mary_datum  :  ref  er  (concentrici ty_toler__datum)  ; 
secondary  datum  :  OPTIONAL  ref er (concentricity  toler  datum); 
END;  “  *  ”  ” 


ENTITY  cyl indricity_toler ; 

NOROLE 

name  :  STRING; 

ROLE 

applies  :  LISTCl  to  *  )  OF  REFER (cyl indr i ci ty_tol er_object ) ; 
toler_value  :  t_4nagni tude; 

END; 


ENTITY  f latness_toler; 

NOROLE 

name  :  STRING; 

ROLE 

applies  :  LISTd  to  *  )  OF  REFER(f latness_toler_object) ; 
toler_value  :  t_magnitude; 

material_conditi on  ;  t_mater i al _condi ti on; 
unit_square  :  ; 

END; 


PDES  SCHEMA 


ENTITY  parallelism  toler; 

NOROLE 

name  t  STRING; 

OLE 

applies  :  LISTd  to  *  )  OF  REFER  (par  al  1  el  i  sm_tol  er_object; 
toler_value  :  t_magni tude; 

primary_datum  :  re-f  er  (paral  lei  ism_toler  datum); 

END; 


ENTITY  perpendicularity  toler; 

NORQLE 

name  :  STRING; 

ROLE 

applies  :  LISTd  to  *  )  OF  REFER  (perpendi  cul  arity_tol  er^object ) 
toler_value  :  t.magnitude; 

pr i mary_datum  :  re-fer  <perpendicularity_toler_datum> ; 

END; 


ENTITY  position  toler; 
NOROLE 


name  :  STRING; 

ROLE 

applies  :  LISTd  to  *  )  OF  REFER  (positi  on_tol  er_object ) ; 
toler_value  ;  t_,magni tude; 

primary_datum  :  re+er (posi ti on_toler_datum) ; 
secondary_,datum  :  re-f  er  (posi  tion_toler_datum>  ; 
tertiary  ..datum  :  re+er  (posit  ion_tol  Br_datum> ; 

ND; 


ENTITY  prof i 1 e_l ine_tol er ; 

NOROLE 

name  :  STRING; 

ROLE 

applies  :  LISTd  to  *  )  OF  REFER (prof i le_l ine_toler_ob ject ) ; 
toler_value  :  t^magnitude; 

pr i mary_datum  :  ref er (prof i 1 e_l ine_tol er_datum) ; 
secondary_datum  ;  OPTIONAL  refer (prof i le_l ine_toler_datum) ; 
terti ary_datum  ;  ref er (prof i le_l ine_toler_datum) ; 

END; 


ENTITY  profile  surface  toler; 

NOROLE 

name  :  STRING; 

ROLE 

applies  :  LISTd  to  ♦  )  OF  REFER (prof i le_surface_toler_ob ject d 
toler_value  ;  t_magnitude; 

pri mar y_datum  :  ref er (prof i 1 e_surfac^_tol er_datum ) ; 
Becondary_datum  :  OPTIONAL  ref er (prof i le_surf ace_toler_datum> ; 
ter t 1 ary_datum  :  ref er (prof i 1 e_surface_tol er_datum) ; 


PDES  SCHEMA 


ENTITY  straightness_toler; 

NOROLE 

name  :  STRING; 

ROLE 

applies  :  LISTd  to  *  )  OF  REFER (strai ghtness_tol er_object ) 
toler_value  :  t  magnitude; 

END; 


ENTITY  total  runout_tol er ; 

NOROLE 

name  :  STRING; 

ROLE 

applies  I  LISTd  to  *  )  OF  REFER (total _runout_tol er_object ) 
toler_value  t  t_magnitude; 

primary_datum  :  re-fer  (total_runout_toler_datum)  ; 
secondary  datum  :  OPTIONAL  re-fer  <total_runout_toler_datum)  ; 
END; 
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NOTE:  These  definitions  were  approved  by  the 
IGES  FEM  Conmittee  on  Oct  16,  1985. 


APPROVAL  -  This  is  an  attribute  of  a  model,  refering  to  the 
model's  acceptance  by  the  creating  organization. 

CONNECTIVITY  CROSS  REFERENCE  (CR)  -  the  assignment  of  a  node  to 
an  element.  This  refers  to  a  single  occurence  of  this  cross 
reference  (CR) ,  not  a  list  of  all  the  multiple  occurences  of 
this  entity. 

COORDINATE  SYSTEM  -  a  frame  of  reference  used  to  define  the 
location  of  a  FEM  or  its  components  in  3D  space. 

COORDINATE  SYSTEM  TYPE  -  This  is  a  label  which  is  used  to 
distinguish  between  cartesian,  cylindrical  and  spherical 
coordinate  systems. 

CREATING  SOFTWARE  -  The  neu&e  of  the  software  package  used  to 
create  the  FEM  model. 

CREATION  DATE  -'•The  date  on  which  the  FEM  model  was  created. 

CREATION  TIME  The  time  of  day  that  the  model  was  created. 

Time  and  date  may  be  used  to  distinguished  between  similar  models. 

DEFINING  COORDINATE  SYSTEM  -  A  coordinate  system  used  to  define 
the  location  of  a  FEM  entity.  [See  Comments  at  end  of  document] 

DESCRIPTOR  -  Text  associate  with  the  model  which  can  contain 
any  information  about  the  model  supplied  by  the  creator. 

ELEMENT  -  basic  FEM  building  block  defining  the  relationship 
between  its  nodes. 

ELEMENT/ENVIRONMENT  CR  -  the  assignment  of  am  environment  to  an 
element.  This  refers  to  a  single  occurence  of  this  cross 
reference,  not  a  list  of  all  the  multiple  occurence  of  this 
entity. 

ELEMENT/GROUP  CR  -  assignment  of  an  element  to  a  group.  This 
refers  to  a  single  occurence  w  of  this  cross  reference  (CR) ,  not 
a  list  of  all  the  multiple  occurences  of  this  entity. 

ELEMENT/GEOMETRIC  PROPERTY  CR  -  assignment  of  a  geometric 
property  to  an  element.  This  refers  to  a  single  occurence  of 
this  cross  reference  (CR) ,  not  a  list  of  all  the  multiple 
occurences  of  this  entity. 


element  order  -  the  aathesatical  definition  for  the  allowable 
deformation  of  an  element  edge.  An  element  with  nodes  only  at 
comers  is  linear  or  first  order  element.  An  element  with  an 
additional  node  on  each  edge  between  comer  nodes  is  a  par2d3olic 
or  second  order  element.  The  order  equals  the  number  of 
non-comer  nodes  per  element  edge  plus  one.  The  element  order 
md  the  element  shape  together  imply  an  expected  number  of  nodes 
to  define  the  element.  Missing  nodes  are  caused  by  transition 
elements,  and  excess  nodes  imply  face-located  nodes. 

ELEMENT  PURPOSE  DESCRIPTOR  -  Text  which  is  used  to  describe  the 
intended  purpose  for  a  particular  element,  and  generally  to 
define  the  limitations  of  the  element  capabilities.  This  may  be 
important  for  element  mapping  between  dissimiliar  analysis 
codes.  For  exzunple,  a  four-noded  element  could  be  a  membrane 
element,  a  bending  element,  a  shear  peuiel,  or  a  plate  element 
with  coupled  bending  and  membrane  behavior.  This  item  will 
distinguish  between  geometrically  similar  element  types. 

ELEMENT  SHAPE  DESCRIPTOR  -  Text  which  is  used  to  describe  the 
shape  of  a  particular  element,  i.e.  wedge,  brick,  quad, 
triangle . 

ENVIRONMENT  -einy  external  or  internal  influence  on  a  FEM. 

ENVIRONMENT/GROUP  CR  -  assignment  of  am  environment  to  a  group. 
This  refers  to  a  single  occurence  of  this  cross  reference  (CR) , 
not  a  list  of  all  the  multiple  occurences  of  this  entity. 

ENVIRONMENT  TYPE  -  A  laUsel  that  defines  the  type  of  environment 
being  specified  from  a  list  of  availadale  types.  For  example, 
load  or  constraint. 

FEM  -  finite  flement  Ijodel  -  a  collection  of  elements  and 
nodes  that  approximates  a  part  or  assembly;  it  may  include 
geometric  and  material  properties  amd  an  environment. 

GEOMETRIC  PROPERTY  -  values  that  may  be  used  to  describe  the 
physical  characteristics  of  an  element.  For  example,  shell 
element  thiclcness,  beaus  element  area  moment  of  inertia, etc. 

GEOMETRIC  PROPERTY  TYPE  -  A  label  that  defines  the  type  of 
geometric  property  being  specified  from  a  list  of  availadsle 
types.  For  example,  shell,  beam  or  composite  layup  properties. 

GROUP  -  a  collection  of  FEM  nodes,  FEM  elements  or  FEM 
environments  or  any  combination  thereof. 

LENGTH  UNIT  -  the  selected  unit  for  specifying  length  throughout 
the  model,  such  as  inches  or  meters. 

MASS  UNIT  -  the  selected  unit  for  specifying  mass  throughout  the 
model,  such  as  kilograms  or  slugs. 


MATERIAL  PROPERTY  ~  values  that  nay  be  used  to  describe  the 
constitutive  nature  of  an  element  or  a  node. 

MATERIAL  PROPERTY  TYPE  -  A  label  that  defines  the  type  of 
material  property  being  specified  from  a  list  of  available 
types.  For  exeuaple,  mechanical,  thermal  or  electrical 
properties . 

NODE  a  geometric  location  in  a  FEM;  used  to  define  elements 
and  environments. 

NODE/ COORDINATE  SYSTEM  CR  -  The  assignment  of  a  coordinate  system 
to  a  FEM  node.  This  refers  to  a  single  occurence  of  this  cross 
reference,  not  a  list  of  all  the  multiple  occurences  of  this 
entity. 

NODE/ENVIRONMENT  CR  -  the  assignment  of  an  environment  to  a 
node.  This  refers  to  a  single  occurence  of  this  cross 
reference,  not  a  list  of  all  the  multiple  occurences  of  this 
entity . 

NODE  COORDINATE  1  -  The  first  value  from  an  ordered  set  of  three 
values  that  define  the  spatial  location  of  a  node. 

NODE  COORDINATE  2  •  The  second  value  from  an  ordered  set  of  three 
values  that  define  the  spatial  location  of  a  node. 

NODE  COORDINATE  3  -  The  third  value  from  an  ordered  set  of  three 
values  that  define  the  spatial  location  of  a  node. 

NODE/GROtJP  CR  -  assignment  of  a  node  to  a  group.  This  refers  to 
a  single  occurence  of  this  cross  reference  (CR) ,  not  a  list  of  all 
the  multiple  occurences  of  this  entity. 

NODE/MATERIAL  PROPERTY  CR  -  assignment  of  a  material  property  to 
a  node.  This  refers  to  a  single  occurence  of  this  cross 
reference,  not  a  list  of  all  the  multiple  occurences  of  this 
entity. 

NODE  SEQUENCE  NUMBER  -  The  number  which  represents  the  position 
of  a  node  in  a  ordered  list  of  nodes  which  defines  an  element, 

(the  connectivity  list) .  A  single  instemce  of  the  connectivity 
CR  entity  will  use  this  sequence  nximber  to  cross  reference  a 
node  with  a  particular  location  on  a  particular  element. 

ORIGIN  -  The  position  in  a  coordinate  system  located  with  all 
zero  coordinate  values. 

PART/FEM  CR  -  the  assignment  of  a  FEM  to  a  part.  This  refers  to 
a  single  occurence  of  this  cross  reference  (CR) ,  not  a  list  of  all 
the  multiple  occurences  of  this  entity. 

TEMPERATURE  UNIT  -  the  selected  unit  for  specifying  temperature 


throughout  the  model,  such  as  degrees  Centigrade  or  Reuikine. 


TRANSFORMATION  MATRIX  -  The  matrix  used  to  specify  the 
orientation  and  location  of  an  entity  in  space,  as  well  the 
scale  of  the  entity. 

TIME  UNIT  -  the  selected  unit  for  specifying  time  throughout  the 
the  model,  such  as  seconds  or  hours. 


RULES 

1.  Any  change  in  a  FE  Model  will  result  in  a  new  model,  and 
therefore,  requires  a  new  FEM  ID. 

2.  Any  sequence  number  in  the  FEM  connectivity  entity  greater 
than  those  indicated  by  order  and  shape  must  refer  to  an  excess 
node  or  several  excess  nodes. 


COMMENTS  AND  SUGGESTIONS 

1.  The  "defining  coordinate  system"  is  only  used  in  the  NQDE 
entity,  and  probably  should  be  replaced  there  by  "coordinate 
system"  since  the  defining  coordinate  system  definition  and  the 
coordinate  system  definition  are  essentially  identical.  This 
means  changing  toe  non-key  attribute  name  in  toe  NODE  entity  and 
eliminating  toe  definition  from  toe  data  dictionary. 

2.  The  PART/FEM  CR  entity  may  or  may  not  be  appropriate,  since 
we  removed  toe  PART  definition  from  this  data  dictionary. 

W.  R.  Freeman 

Allied  Signal  Bendix  Aerospace 
Oct  19 8 5/ corrections  Jan  1986 


Natural  Language  Version  of  lA  Model,  Derived  from 
IDEF  Model  created  by  IGES  FEM  Subcommittee 

NOTE:  These  statements  are  only  valid  when  the  terms 
used  are  defined  as  per  the  FEM  IDEF  Model 
dictionary  of  terms. 

1.  A  defining  coordinate  system  may  have  many  nodes. 

2.  An  approval  may  be  for  many  models. 

3.  An  author  may  create  mzmy  models. 

4.  A  connectivity  must  always  have  only  one  node  sequence 
number. 

5.  A  connectivity  must  always  have  only  one  node. 

6.  A  connectivity  must  always  refer  to  only  one  element. 

7.  A  coordinate  system  may  be  referenced  by  many  node/coordinate 

system  CRs. 

8.  A  coordinate  system  type  may  refer  to  mamy  coordinate  systems. 

9.  A  coordinate  system  must  always  have  only  one  coordinate  system 
type 

10.  A  coordinate  system  must  always  have  only  one  transformation 
matrix . 

11.  A  coordinate  system  must  always  have  only  one  origin. 

12.  A  coordinate  system  may  be  referenced  by  many  material 

properties . 

13.  A  coordinate  system  must  always  refer  to  only  one  model. 

14.  An  origin  may  refer  to  many  coordinate  systems. 

15.  Creating  software  may  refer  to  many  models. 

16.  A  creation  date  may  refer  to  many  models. 

17.  A  creation  time  may  refer  to  many  models. 

18.  A  descriptor  may  refer  to  many  models. 

19.  An  element/ environment  CR  must  always  refer  to  only  one 
environment. 

20.  An  element/environment  CR  must  always  refer  to  only  one  element 


An  element/geometric  property  CR  must  always  refer  to  only  one 
geometric  property.  ^ 

An  element/geometric  property  CR  must  always  refer  to  only  on^ 
element . 

An  element/group  CR  must  always  refer  to  only  one  group. 

An  element/ group  CR  must  always  refer  to  only  one  element. 

An  element/material  property  must  always  refer  to 
only  one  material  property. 

An  element/material  property  must  always  refer  to 
only  one  element. 

An  element  order  may  refer  to  more  than  one  element. 

An  element  must  always  have  only  one  purpose  descriptor. 

An  element  must  always  have  only  one  element  order. 

An  element  must  always  have  only  one  shape  descriptor. 

An  element  may  be  refered  to  by  many  element/environment 
CRs. 

An  element  may  be  refered  to  by  many  element/material  M 

property  CRs .  ^ 

An  element  may  be  refered  to  by  many  element/geometric 
property  CRs. 

An  element  may  be  refered  to  by  many  element/ group  CRs. 

An  element  must  always  be  referred  to  by  many 
connectivities . 


An  element  must  always  refer  to  only  one  FEM  model. 

An  element  must  always  have  only  one  element  number. 

An  envir  ^nment/group  CR  must  always  refer  to  only  one  envirorunen 
An  environment/group  CR  must  always  refer  to  only  one  group. 

An  environment  type  may  be  used  by  many  environments. 

An  environment  may  refer  to  many  element/environment  CRs. 


42.  An  environment  may  be  referenced  by  many  environment/group 
CRs. 


43.  An  environment  must  always  have  only  one  environment  type. 

44.  An  environment  may  be  referenced  by  many  node/ environment 
CRs. 

45.  An  environment  may  be  referenced  by  many  element/environment 
CRs. 

46.  An  environment  may  include  restraints. 

47.  An  environment  may  include  constraints. 

48.  An  environment  may  include  temperatures. 

49.  An  environment  may  include  loads. 

50.  A  geometric  property  type  may  refer  to  many  geometric 
properties . 

51.  A  geometric  property  must  always  have  only  one  geometric 
property  type. 

52.  A  geometric  property  may  include  beeun  geometric 
properties . 

53 .  A  geometric  property  may  be  referenced  by  many  element/ geometri 
property  CRs. 

54.  A  geometric  property  may  include  a  composite  layup. 

55.  A  geometric  property  may  include  point  geometric 
properties . 

56.  A  geometric  property  may  include  shell  geometric 
properties . 

57.  A  group  type  may  refer  to  metny  groups. 

58.  A  group  must  always  be  of  only  one  group  type. 

59.  A  group  may  have  only  one  node/group  CR. 

60.  A  group  may  have  only  one  element/group  CR. 

61.  A  group  may  have  only  one  environment/group  CR. 

62.  A  group  may  include  a  region. 

63 .  A  group  may  include  a  color. 

64.  A  group  must  always  refer  to  only  one  model. 

65.  A  length  \init  may  be  used  in  many  models. 


66.  A  mass  unit  may  be  used  in  memy  models. 

67.  A  material  property  type  may  refer  many  material  properties. 


A  Material  property  must  always  have  only  one  material 
property  type. 

A  material  property  must  always  reference  zero  or  one  coordinate 
system. 

A  material  property  may  be  referenced  by  many  node/material 
property  CRs. 

A  material  property  may  refer  to  many  element/material 
property  CRs. 

A  material  property  may  include  electrical  properties. 

A  material  property  may  include  acoustical  properties. 

A  material  property  may  include  thermal  properties. 

A  material  property  may  include  mechanical  properties. 

Node/ environment  CRs  must  always  refer  to  only  one  environment. 


A  node/ environment  CR  must  always  refer  to  only  one  node. 

Node/material  property  CR  must  always  refer  to  only  one  mateuj^ 
property.  MB 

A  node/material  property  CR  must  always  refer  to  only 
one  node. 

Node/coordinate  system  CRs  must  always  refer  to  only 
one  node. 

A  node/coordinate  system  CR  must  always  reference  only 
one  coordinate  system. 

Node  coordinate  1  may  refer  to  many  nodes. 

Node  coordinate  2  may  refer  to  many  nodes. 

Node  coordinate  3  may  be  used  by  many  nodes. 

A  node/group  CR  must  always  refer  to  only  one  group. 

A  node/ group  CR  must  always  refer  to  only  one  node. 

A  node  sequence  number  may  be  referenced  by  many  connectivities. 
A  node  may  reference  many  node/coordinate  system  CRs. 


Appendix  C6.2 
Task  2 


Finite  Element  Modeling  Qualified  Model  fNIAM^ 


(DISCIPLINE) 
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Finite  Element  Modeling  Global  Model  (NIAM) 

(DISCIPLINE) 
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Geometry-Topoloav  Associativity  Resource  Model  fNIAM^ 


(RESOURCE) 
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PDES  SCHEMA 


-  TOPOLOGY  SCHEMA 

-  VERSION  0,0 

LASS  topology  OF 
(verte::  ,  edge,  1 


OOP, 


■face,  shel  1  , 


object  > ; 


ENTITY  verte:;; 

NOROLE 

name  ;  OPTIONAL  string; 
ROLE 

basepoint  :  REFER (point ) ; 
END; 


ENTITY  edge; 

NOROLE 

name  ;  OPTIONAL  string; 
ROLE 

basecurve  :  REFER (cur ve)  ; 
limitO  :  REFER  (vertex. )  ; 
limitl  :  REFER (vertex )  ; 
END; 


ENTITY  loop; 
NOROLE 


name  : 

^PiOLE 

member 

END; 


OPTIONAL  string 
:  LISTd  TO  ♦) 


> 

OF  REFER (edge); 


ENTITY  -face; 

NOROLE 

name  :  OPTIONAL  string; 

ROLE 

basesLir-face  :  REFER  (sur -face)  ; 
bound loop  :  REFER (loop); 

interior loop  :  LIST (0  TO  ♦)  OF  REFER (loop) 
END; 


ENTITY  shell; 

NOROLE 

name  i  OPTIONAL  string; 

ROLE 

member  ;  LISTd  TO  ■»)  OF  REFER  (-face)  ; 
END; 


PDES  SCHEMA 


ENTITY  object; 

NOROLE 

name  :  OPTIONAL  string; 

ROLE 

boundshell  ;  REFER (shel 1 ) ; 

interiorshell  ;  LIST(0  TO  ♦)  OF  REFER (shel 1 ) ; 
END; 


iiiaiA  IIN<  tn  laiA  laais  »'•<  <ai4  isaaaaai 
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Topology  Resource  Model 
(RESOimCE} 


C7 . 1  NIAM  Model 
C7 . 2  nSL  Model 
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Dl.  IDEF-l  And  IDEF-1  Extended  (IDEFl-X) 

D2.  Kijssen  Information  Analysis  Method  (NIAM) 
D3.  Data  Specification  Language  (DSL) 
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PDES  INITIATION  EFFORT  REPORT 

APPENDIX  D1 
PART  1 


A  BRIEF  OVERVIEW  OF  THE 
IDEF1X  MODELING  METHODOLOGY 

Prepared  by  Roger  Gale 

In  this  Appendix,  references  to  Conceptual  Schema.  External  Schema  and  Internal  Schema  are  based 
upon  the  concepts  advanced  by  the  ANSi/X3/SPARC  committee. 

IDEF1X  is  the  latest  version  of  the  Data  Modeling  methodology  developed  under  the  USAF ICAM  project. 
Because  of  the  USAF  ICAM  contracts,  it  is  probable  that  more  product  data  modeling  has  been  performed 
in  IDEF1 X  and  its  original  version,  IOEF1 ,  than  in  any  other  methodology. 

It  is  important  that  the  reader  understand  that  tOEFIX  is  a  language  with  syntax  and  semantics  for 
expressing  a  data  model  olua  a  discipline,  or  method,  for  developing  the  model.  A  data  model 
representing  a  portion  of  the  Conceptual  Schema  of  an  enterprise  may  only  be  reached  if  the  discipline  is 
applied.  The  modeling  language  in  and  of  itseH  does  not  guarantee  a  Conceptual  Schema  model. 
Persons  using  the  language  without  understanding  and  applying  the  discipline  tend  to  model  portions  of 
an  External  Schema  or  Internal  Schema. 

The  developers  of  IOEF1X  assigned  overriding  importance  to  its  use  to  comnunicate  among  humans. 
There  is  a  belief  that  a  Conceptual  Schema  demanrte  considerable  review  by  people  before  the  rules 
embodied  in  it  have  been  validated.  Therefore,  the  language  consists  of  graphics  and  text  with  the  most 
semantically  important  ideas  being  given  gra^ic  tonportance  as  an  aid  to  that  necessary  human 
communication. 

The  largest  text  portion  of  the  model  is  the  Glossary  in  which  all  names  of  entities  and  attributes  are 
defined.  Another  text  portion  contains  identification  of  constraints  which  are  not  shown  graphically  such 
as  Data  Types  and  Domains  for  Attributes,  and  Path  Assertions. 

Part  1  of  this  appendix  is  primarily  a  brief  explanation  of  the  discipline  for  developing  an  IDEF1X 
conceptual  model.  Part  2  is  an  explanation  of  the  graphic  syntax  and  semantics.  Part  3  explains  the 
differences  between  IDEF1  and  IDEF1X 

The  discipline  for  IDEF1 X  is  aseries  of  steps  beginning  with  definition  of  the  areas  of  the  enterprise  which 
are  of  interest  and  continuing  through  a  series  of  specific  refinements  to  a  fourth  normal  fom,  relational 
model.  Within  the  scope  of  interest,  this  is  a"top  <k)wn*  methodology.  It  permits  modelers  to  begin  with  a 
model  of  considerable  abstraction  and  progress  in  steps  to  the  desired  degree  of  detail. 

in  the  paragraphs  which  follow,  the  sequence  of  lOEFf  X  modeling  steps  is  outlined  very  briefly.  The 
reader  should  rtot  expect  to  be  able  to  rrxtdel  adequately  from  this  material.  A  detailed  text  can  be 
obtained  from  the  USAF.  For  information  about  obtaining  a  copy  it  is  suggested  that  the  following  person 
be  contacted: 

David  L.  Judson 

AFWAUMLTC 

Bldg.  653.  Area  B.  Room  221 

Wright  Patterson  AFB,  Ohio  45433-6533 

(513)  255-6976 
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The  modeling  procedure  has  five  phases.  The  initial  phase  is  Phase  0.  In  phase  0,  the  scope  and 
objectives  of  the  modeling  project  are  established.  One  of  the  key  factors  is  to  define  whether  the  model 
is  to  represent  an  "AS-iS*  condition  or  a  TO-BE”  condition. 

Phase  1  involves  the  initial  defintion  of  Entities.  Phase  2  defines  the  relationships  among  the  entities. 
Phase  3  defines  keys  for  each  entity.  In  Phase  4,  non-key  attributes  are  defined  and  final  refinement  of 
the  model  is  performed. 

PHASE  1 

The  first  step  is  to  create  an  Entity  Pool.  An  Entity  is  defined  as  a  kind  of  thing  about  which  the  enterprise 
keeps  data.  The  thing  may  be  concrete  such  as  an  en^ioyee  or  a  machine,  or  an  abstract  thing  such  as  a 
schedule  event.  There  are  tests  for  entities.  Each  instance  of  an  entity  must  have  a  unique  identifier.  For 
example,  each  employee  has  a  unique  employee  number  assigned  by  the  enterprise.  There  should  be 
attributes  (properties  or  characteristics)  of  the  entrty  which  represent  data  the  enterprise  maintains.  In  the 
employee  case,  the  enterprise  normally  keeps  data  about  such  attributes  as  name,  birth  date, 
employment  date.  etc. 

Each  carxjidate  entity  rrtust  be  given  a  definition  and  a  name.  There  may  be  a  variety  of  names  in  common 
use  in  the  enterprise  which  are  applied  to  the  entity.  However,  in  orderthat  the  model  wiD  have  stability,  a 
specific  definition  and  name  must  be  chosen  as  the  Conceptual  name.  A  basic  rule  for  a  conceptual 
model  is  ’same  name/same  meaning”. 

PHASE  2 

The  next  step  is  to  discover  the  direct  reiationsh^s  among  the  entities,  it  is  recommended  that  this  be 
started  by  preparing  a  matrix  with  the  list  of  candidate  entities  on  each  axis.  Then  each  pair  of  entities  is 
examined  to  determine  if  there  is  a  direct  relationship  between  them.  If  there  is,  an  ”X”  is  placed  attha'. 
intersection  of  the  matrix.  It  is  useful  here  if  sentences  are  written  stating  how  the  entities  are  related.  For 
example: 

During  his  tenure  with  the  company  an  Employee  is  assigned  to  one  or  more  Departments. 

A  Department  has  many  assigned  Employees. 

From  the  entity  relationship  matrix,  an  initial  entity-rstationship  diagram  is  drawn.  This  cSagram  uses  the 
entity  boxes  and  relationship  lines,  labels  and  cardinality  symbols  shown  in  Part  2  of  this  appendix.  The 
relationships  are  defined  and  labelled.  At  this  stage,  many  of  the  relationships  wiD  be  non-specific  (i.e. 
many-to-many).  The  definition  of  the  realtionship  between  two  entities  must  be  examined  in  both 
directions.  Determine  how  many  instances  of  one  entity  can  be  related  to  one  instance  of  the  other  entity 
in  each  direction.  The  relationship  must  be  labeled.  If  it  is  non-specific,  the  relationship  must  be  labeled  to 
describe  the  relationship  in  each  direction.  A  specific  relationship  only  requires  a  label  reading  from  parent 
to  child. 

Here  it  is  important  to  remember  that  it  is  the  data  of  the  enterprise  which  is  being  modeled  not  a  computer 
system.  Computer  systems  have  frequently  been  developed  so  that  their  data  files  contain  only  the 
current  knowledge.  Meanwhile,  the  enterprise  keeps  copies  of  former  states  of  knowledge.  A  computer 
system  may  only  show  the  name  of  the  current  General  Manager  of  a  Division.  The  records  of  the  Division 
show  al  previous  General  Managers.  Consequently,  the  enterprise  data  model  should  show  that  a 
Division  has  one  or  many  General  Managers. 
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PHASE  3 


The  objectives  of  Phase  3  are  to: 

Refine  the  non-specific  relationships  from  Phase  2. 

Define  key  attributes  for  each  entity. 

Migrate  primary  keys  from  parent  entities  to  child  entities  to  establish  foreign  keys. 

Validate  relationships  and  keys. 

The  next  step  is  to  resolve  all  non-specific  relationships.  The  non-specific  relationships  from  the  inKial 
diagram  must  be  refined  into  existence-dependency  (parent-child)  relationships  or  generalization 
relationships  (see  Part  2  for  examples).  The  process  of  refining  norvspecific  relationships  converts  each 
non-specific  relationship  into  two  specific  relationships.  New  entities  evolve  out  of  this  process.  Each  of 
the  new  entities  must  be  provided  a  name  and  defintion  in  the  Glossary.  Entities  resulting  from  this 
process  are  informally  referred  to  as  ’derived  entities”.  A  derived  entity  tends  to  be  more  abstract  than  the 
initial  business  er^^ities. 

When  specific  realtionships  have  been  defined,  it  is  time  to  establish  ’keys”  for  each  entity.  A  key  is  an 
attribute,  or  concatenation  of  two  or  more  attributes,  which  will  uniquely  identify  a  single  occurrence  of  an 
entity.  Carxlidate  keys  are  developed  and  defined  for  each  entity. 

When  an  entity  has  more  than  one  candidate  key,  one  must  be  established  as  the  prvnary  key  and  the 
others  identified  as  alternate  keys.  Alternate  keys  are  shown  below  the  line  in  the  entity  box  and  identified 
by  placing  (AKn)  following  their  name  (see  Part  2  examples).  Because  there  may  be  more  than  one 
alternate  key,  the  *n”  is  a  number  indicating  which  attributes  belong  to  which  alternate  key.  Keys  are  an 
attribute,  or  combination  of  attributes,  of  the  entity.  Each  of  the  key  attrflsutes  must  be  provided  a 
definition  and  name  in  the  model  glossary. 

The  Primary  Key  of  each  parent  entity  must  be  migrated  to  each  of  its  child  entities.  It  may  migrate  to 
become  part  of  the  key  of  a  child,  or  it  may  migrate  as  a  non-key  attrSjute  of  the  child,  in  either  case,  it  is 
shown  in  the  child  and  identified  as  aloreign  key”  by  placing  (FK)  after  its  name  in  the  child.  Role-names 
are  assigned  to  migrated  keys  as  required  (see  Part  2  role  name  examples). 

Key  attributes  must  be  validated  by  testing  that  they  conform  to  several  rules  as  follows; 

1 .  No  attribute  of  an  entity  may  have  more  than  one  value  for  each  instance  of  the  entity  (No-Repeat 
njie) 

2.  No  attribute  of  an  entity  may  have  a  null  valuator  any  instance  of  the  entity  (No-Null  oile). 

3.  Where  an  entity  has  a  compound  key,  it  must  not  be  possible  to  split  that  entity  into  multiple 
entities  with  simpler  keys  (Smallest-Key  rule). 

4.  Where  there  are  dual  relationship  paths  between  two  entities,  assertions  must  be  made  as  to 
whether  both  paths  from  the  dependent  entity  reach  the  same  or  different  instances  of  the 
independent  entity  (Path  Assertions). 
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PHASE  4 


After  the  relationships  have  been  refined  and  keys  established,  the  next  step  is  to  determine  the  non-key' 
attributes  of  each  entity.  For  each  entity,  candidate  attributes  are  listed.  These  represent  the  properties 
or  characteristics  of  each  entity  about  which  the  enterprise  mairtains  data.  Each  carxtidate  attribute  must 
be  given  a  definition  and  name  in  the  model  glossary. 

Each  candidate  attribute  is  assigned  to  an  entity,  its  ’owner*.  Attributes  are  then  tested  with  the 
’No-Repeat’  and  ’No-NuH’  rules.  Attributes  which  viloate  the  rules  require  the  introduction  of  new 
’derived’  entities  for  their  ownership.  These  new  entities  must  be  named  and  defined  in  the  Glossary, 
their  appropriate  relationships  defined  and  keys  migrated  to  them. 

An  additional  rule  must  be  applied  now.  It  is  applied  to  attributes  of  entities  with  compound  keys.  This  is 
the  Full-Functional-Dependency  rule.  This  mle  requires  that  no  owned  attribute  value  of  an  entity 
instance  can  be  identified  by  less  than  the  entire  key  value  for  the  instance.  The  correct  application  of  this 
rule  is  equivalent  to  the  second  normal  form  of  reiationai  theory. 

A  final  rule  is  the  No-TransHive- Dependency  rule.  This  oiie  requires  that  no  owned,  non-key  attribute 
value  of  an  entity  instance  can  be  identified  by  the  value  of  another  owned,  or  inherited,  non-key  value  of 
an  attribute  of  the  entity  instance.  This  rule  is  equivalent  to  third  normal  form  in  ralational  theory. 

These  last  two  rules  can  be  summed  up  in  the  statement:  ’a  non-key  attribute  must  be  dependent  upon 
the  key,  the  whole  key  and  nothing  but  the  key’. 

SUMMARY 

The  IDEF1X  modeling  methodology  is  a  top  down”  method  which  starts  with  abstraction  and  progresses 
to  required  detail.  It  utilizes  the  Entity  idea  to  collect  data  (Attributes)  in  the  manner  in  which  they  appear 
in  the  enterprise  being  modeled.  When  the  model  is  fully  refined  according  to  the  njles,  each  entity 
represents  a  statement  that  values  for  afl  of  the  attributes  of  that  entity  appear  at  the  same  time  and  place 
within  the  enterprise. 

The  IDEF1 X  modeling  language  and  discipline,  when  used  by  trained  modelers,  and  properly  validated  will 
result  in  the  definition  of  a  stable  Conceptual  Schema  For  PDES,  instability  in  the  Logical  Layer 
Conceptual  Schema  will  result  in  compatibility  problems  among  versions  which  is  an  undesirable 
characteristic. 

The  IDEF1X  language  is  not  only  useful  for  modeling  a  Conceptual  Schema.  It  may  also  be  used  as  a 
planning  tool  by  preparing  models  of  high  degrees  of  abstraction  to  illustrate  fundamental  data 
relationships  in  an  enterprise.  The  next  two  pages  are  an  example  of  such  a ’Data  Planning  Model’.  This 
model  is  at  a  very  high  degree  of  abstraction.  For  example,  I  have  been  working  with  an  enterprise  where 
there  is  a  model  containing  about  300  entities  which  are  represented  by  the  handful  of  entities  on  the 
second  page.  Such  models  are  used  to  establish  scopes  of  projects  by  examining  data  affinities.  This 
model  probably  represents  a  significant  percentage  of  the  potential  future  coverage  of  PDES. 
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WHAT  IS  NIAM? 


1.  A  binary  semantic  conceptual  model. 

2.  A  means  of  capturing  (complex)  information 
requirements  in  user  understandable  terms, 

modeling  and  analyzing  the  requirements  in  a 
feature— rich  formal  information  model, 

and  translating  conceptual  information 
requirements  into  implementable  specifications. 


WHY  NIAM? 


0  More  power  and  precision  in  knowledg'=> 
representation 

0  More  discipline  and  rigor  in  the  methodologv’ 

0  Greater  user  (expert)  participation 

0  Cleaner  separation  of  expert  models  from 
specification  models 

0  Easier  generation  of  neutral  data  model 
specifications 


o  More  real-world  semantics  for  data  and  rule  bases 
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User-Machine  Gap 


LANGUAGE , 

COGNITIVE  STRUCTURES 

1 

BINARY  SEMANTIC 
MODELS 
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NEUTRAL  DATA 
MODELS 
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DATABASE 

I 

DATA  STRUCTURE 
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BACKGROUND 


Recognition  of  need  for  better  data  modeling 
techniques 

NlAM  research  into  information  analysis 

ANSI/X3/SPARC  -  3  Schema  Architecture 
Conceptual  Schema  proposal 

NlAM  real-world  applications 

NlAM  released 

IFIP-CRIS  conferences 
NlAM  rated  high 

ISO  TC97/SC5/WG3 

Evaluation  of  Conceptual  Schemas  proposals 
NlAM  selected  as  binary  approach 

NlAM  used  within  PDES  initiation  effort 

NLAM  usage  worldwide 

>  120  organizations 

>  5  universities 
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Concept  Type 


A  concept  type  is  a  set  of  instances  within  a  Universal  of  Discourse  havin 
common  properties. 

A  concept  type  is  independent  from  symbols  used  to  represent  it. 

A  subtype  shares  (inherits)  all  properties  of  its  supertype.  A  subtype  ma 
have  multiple  supertypes. 


CONTTRpL 

[DATA 


Total  Subtype  Constraint 

> 


A  total 
concept 


subtype  constraint  prescribes  that  for  every  occurrence  of  a  certain 
type  there  must  be  an  occurrence  of  one  of  the  specified  subtypes. 
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Subtype  Exclusion 


A  Subtype  exclusion  constraint  tnutually  excludes  the  sets  of  occurrences  of 
two  or  more  subtypes  within  one  concept  type  family. 
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BIRD 
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Idea  Type 


An  idea  type  is  an  inf ormat ion -bearing  connection  of  concept  types. 

An  idea  type  has  two  different  roles,  each  role  being  played  by  one  concept 
type . 

An  idea  type  can  have  uniqueness  constraint (s )  indicating  the  identifying 
role(s ). 
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Uniqueness  Constraint 


A  uniqueness  constraint  restricts  the  instances  of  one  or  more  roles. 
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Role  Subset  Constraint 


A  subset  constraint  prescribes  that  the  set  of  occurrences  of  one  role  (or 
role  pair)  is  a  subset  of  the  set  of  occurrences  of  another  role  (or  role 
pair ) . 

According  to  the  drawing  conventions,  the  arrow  points  from  domain  to  range 
(indicates  what  implies  what). 
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Total  Role  Constraint 


A  total  role  constraint  prescribes  that,  for  every  occurrence  of  a  concept 
there  must  be  an  occurrence  of  a  specified  role. 


T 
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Role  Exclusion  Constraint 


A  role  exclusion  constraint  prescribes  that  the  set  of  occurrences  of  two 
roles  (or  role  pairs)  must  be  disjoint. 
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Equality  Constraint 


An  equality  constraint  prescribes  that  the  set  of  occurrences  of  two  roles 
must  be  equal. 
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rORKING-rOF 


EMPLOYIK 
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Combined  Constraints 


A  person  may  have  a  primary  skill  and  one  or  more  secondary  skills.  Before 
having  a  primary  ski  11  the  person  must  have  a  secondary  skill.  No  secondary 
skill  may  be  the  duplicate  of  or  equal  to  the  primary. 


» 
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Advanced  Constraints 


Since  each  binary  is  a  logical  predicate,  the  power  of  predicate  logic 
available  in  a  natural  way  for  the  expression  of  complex  constraints. 


for  each  u:  USER 

If  u  makes  an.  INFORMATION  MODEL  describing  a  PROBLEM  ARE.A 
then  u  must  know  the  PROBLEM  AREA. 
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Symbol  Type 


A  symbol  type  is  representable.  It  can  be  used  to  refer  to  a  concept  type 
(also  called  lexical  object  type). 


COWTRpL 

DATA 


Bridge  Type 


A  bridge  type  is  the  name-giving  association  between  a  concept  type  and  a 
symbol  type. 

Depending  on  the  position  of  uniqueness  constraints  on  the  bridge  type,  four 
different  sorts  of  bridge  types  are  recognized: 

-  One-to-one 

-  Synonym 

-  Homonym 

-  Syno -homonym 
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AN  EXAMPLE 


The  next  page  contains  a  small  binary  semantic 
information  model.  Some  of  the  sentences  described  by 
this  model  are: 

^A  user  knows  his  problem  area. 

A  user  makes  an  information  model  which  describes 
the  problem  area. 

An  information  model  is  reviewed  by  an  information 
analyst  and  may  be  implemented  by  a  data  base. 

An  information  expert  may  be  an  information 
analyst  or  an  information  engineer  or  both. 

Before  a  user  can  make  an  information  model,  he 
must  know  hb  problem  area  and  attend  a  training 
course. 


An  information  analyst  must  have  experience." 
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QUERY  PATH/CONSTRAINT 


All  legal  query  relationships  and  accesses  are  defined 
in  the  model.  Invalid  query  paths  cannot  occur. 

This  provides  two  advantages: 

1)  a  high  level  and  very  natural  interface 
to  the  model  information  and 

2)  rejection  of  invalid  accesses. 


EXAMPLE:  HIGH  LEVEL  NATURAL  UNDERSTANDING 


LIST  EXPERIENCE  of  the  INFORMATION  ANALYSTS 
reviewing  the  INFORMATION  MODEL 
describing  the  PROBLEM  AREA 
"Manufacturing  Automation." 


SELECT  EXPERIENCE  FROM  ANALYST- EXPERIENCE 
WHERE  PERSON  #  IN 

SELECT  PERSON  #  FROM  INFORMATION -ANALYST; 
WHERE  PERSON  #  IN 

SELECT  INFORMATION  MODEL-ID  FROM  REVIEWING 
WHERE  INFORMATION-MODEL-ID  IN 
SELECT  INFORMATION-MODEL-ID  FROM  INFORMATION 

WHERE  PROBLEM-AREA-DESCR  = 

"Manufacturing  Automation" 
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EXAMPLE  VALID/IXVALID  QUERIES 


INFORMATION  ANALYST 


Person  S  ! 

« 

P21 

P22 

P23 

Residence  location  : 

Mpls 

Boston 

Seattle 

Work  location  1 

Mpls 

NY 

Seatt  1  e 

Qualification  ‘ 

Cnsl  t 

Analyst 

Cnsl  t 

Valid  —  List  all  information  analysts  whose  residence 
location  is  the  same  as  their  work  location. 

Invalid  ~  List  all  information  analysts  whose  quali¬ 
fication  is  the  same  as  their  work  location. 
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Resolution  of 
Ambiguity 

Vi»M  • 

object  • 
oriantation 

VIEW 


E 


OBJECT 


r  ^ 

VIEW 


ORIEN¬ 

TATION 


ORIEN- 

^ATIO^ 


OBJECT 
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Scope 


A  scope  is  an  abstraction  tool. 

The  scope  concept  serves  the  user  to  abstract  from  details  while  studying  an 
information  system  grammar  and  to  concentrate  attention  on  the  interesting 
part  of  it. 

A  scope  is  a  conglomerate  of  concept  types,  symbol  types,  idea  types,  bridge 
types,  constraints,  and  scopes,  belonging  together  according  to  user 
semantics. 

A  scope  can  be  specified  in  terms  of  other  scopes.  There  are  no  restrictions 
to  the  number  of  concepts  and  the  overlap  of  scopes  in  scopes. 
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Zoom 


A  zoom  is  an  ordered  set  ot  scopes,  each  lower  level  being  more  detailed  than 
a  higher  level. 

Tlierefore,  an,,  concept  present  at  a  certain  level  of  a  zoom  must,  at  least, 
exist  as  such  on  all  lower  levels  of  that  zoom. 

Like  a  scope,  a  zoom  is  a  powerful  abstraction  tool. 

but  the  zoom  mechanism  adds  another  dimension:  a  scope  can  be  seen  as  a  way 
to  stake  out  a  u‘j.at>  area  of  special  interest.  Suppose  that  a  certain  scope 
coinciaes  ^probab.y  not  by  accident;  with  an  intermediate  level  of  a  certain 
zoom;  tnen  it  is  possible  to  zoom  in  and  out  on  that  scope. 

In  tins  way  it  is  possibiC  to  observe  a  certain  area  of  interest  from  a 
distance,  wiinout  its  tirre.evant;  details,  or,  on  the  other  hand,  to  observe 
it  in  great  detail. 

Tiie  aavantage  of  a  zoom  over  a  collection  of  scopes  is  that  the  zoom 
racct'.ar.isr  guarantees  consistency  between  the  levels. 


An  idea/bridge  schc«»  illustrating  the 
grouping  options _ 
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FEATURES  OF  NIAM 


Founded  in  logic  and  set  theory  with  strong  links 
to  linguistic  theory. 

Provides  a  feature- rich  semantic  modeling 
technique  for  high  quality  modeling  efforts. 

Permits  rigorous  analysis  and  specification  by 
user  experts  in  a  language  close  to  their  problem 
description. 

Provides  mathematical  and  linguistics  checks  on 
the  correctness  of  the  model  and  makes  visible 
specification  of  (hidden)  assumptions. 

Maps  easily  to  data  specifications;  this  has  been 
automated  for  normalized  models. 

Has  international  recognition  at  ISO  and  IFIP 
levels.  Is  a  true  ANSI/SPARC  conceptual  schema. 

Proven  in  more  than  ten  years  of  real  world 
experience. 
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SOME  ADVANTAGES  OF  NIAM 


0  User  statements  may  be  captured  naturally  with 
minimal  re— interpretation  by  a  "data  expert." 

0  The  technique  encourages  the  specification  of 

integrity  rules  which  may  be  overlooked  by  other 
techniques. 

0  Mapping  to  the  data  model  (normalization)  is 

automated  and  does  not  have  to  be  performed  by  the 
analyst.  This  avoids  distraction  during  a  user 
session. 

0  All  relationships  are  shown  and  all  views  equally 
valid  yielding  greatest  conceptual  uniformity  and 
simplicity. 

0  More  documented  semantics  and  knowledge  rules 
yield  more  precision  and  less  ambiguity.  The 
Object-Role  style  of  modeling  promotes 
conceptualization. 

0  Some  university  and  industry  experiments  indicate 
a  higher  degree  of  consistency  than  with  other 
techniques. 


0 


The  technique  is  stable,  others  are  still 
evolving. 
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RECAP 


The  NIAM  Binar>'  Semantic  Information  Model  consists  of: 


OBJECT  TYPES  -  Fundamental  categories  of  the  real  world; 
divided  into  two  kinds,  CONCEPTS  and  SYMBOLS. 


SUBTYPES  -  Flexible  generalization  links  between  the 
OBJECT  TYPES. 


FACT  TYPES  -  The  basic  business  rules  of  the  real  world; 
divided  into  two  kinds,  IDEAS  and  BRIDGES; 
all  relationships  (connections)  are  shown. 


INTEGRITY  CONSTRAINTS  -  Integrity  rules  containing 
knowledge  of  valid  system  states  and  transitions; 
basic  SET  ORIENTED  constraints  and  extended 
LOGICAL  PREDICATE  constraints. 


QUERY  CONSTRAINTS  -  The  definition  of  all  legal  queries 
or  processing  access  to  the  knowledge. 
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natural  LAN6UA6E  ANALYSIS, 
INFORNATION  NODELIN6, 

AND  DATABASE  EN61NEERING 


R«ul  Thoapton 
Control  Dot*  Corporation 
Ninnoapolift,  Ntnnttota 


An  ovarvttD  of  foot  concepts  in  knoMledD*  enginterinp  it  presented: 
Hoc  to  analyte  tt)e  content  el  user  expert  natural  language;  ho»>  to 
build  an  Inforaation  Nodel  seaantic  neteork;  and  bou  to  transfer* 
tne  Inforeation  Node!  into  a  database  design. 


(Ocepyright  Paul  Theepson,  IfBS 
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INTRODUCTION 


1. 


TNt  intretfuctien  dat«b*ftt  ttchnelogy  in  tht  IVbO't  cautttf  a  grtat 
cNangt  in  tht  day  inforaatien  ayattaa  atra  dtvilegid. 

Previously  inforaatien  systaos  aara  tat  up  to  oaintain  thair  data  in 
procass'oriantad  files.  Soaa  files  liaulatad  the  tanual  aystaas. 
Others  aara  designed  by  pregraatart  as  scratch  pads  for  data  ahich 
couldn't  all  be  processed  aithin  the  prograa  during  one  ceaputar 
run. 

Database  technology,  on  the  ether  hand,  provided  a  single  control- 
ling  aechanisa  containing  gl]^  of  the  data  needed  by  an  application. 
And  it  stored  the  data  in  a  aay  that  it  aas  easily  accessible  and 
easily  relatable.  This  nea  capability  to  get  at  data  caused  people 
to  thini  of  data  as  having  an  existence  independent  free  the  pro¬ 
gress  Mhich  stored  or  processed  it. 

After  initial  experience  aith  database  technology,  people  realised 
tao  facts: 

1.  Database  technology  is  not  just  a  nea  and  better  file  access 
technique.  It  is  a  radically  different  approach  to  inforoation 
syster  developaent. 

2.  To  eaie  progress  it  is  necessary  to  rethink  concepts  of  data  and 
hoa  it  represents  mforaation  and  to  reaork  our  approaches  to  systes 
design. 

This  paper  presents  soae  of  the  rethinking  ahich  as  taken  place. 


2.  natural  LAN6UAEE  ANALYSIS 

21  It!!  Egisssf  el  leleLiiUee  Sxilies 

Let's  step  back  free  the  coaplenties  of  systea  design,  prograa 
developaent  and  database  eanageaent,  and  loot,  at  the  fundaaental 
nature  of  inforoation  systeos. 

fiuick.  Hhat  do  payroll  systeos,  accounting  aystess,  engineering 
docuoentati on  systeas,  and  clinical  pathological  laboratory  systeos 
have  in  cooaon  ? 

They  are  all  inforoation  systeos. 

They  all  store  and  process  isleieilies  benefit  of  their 

users. 

They  all  store  selected,  pre-deterai ned  categories  of  inferaation  of 
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inttrtft  to  thr  orgonizatien  ontf  loltct,  ceabint  and  praaant  lubiatt 
of  this  inforaation  at  a  tiaa  and  placa  raaota  4roa  tha  captura  of 
tbt  inforaation. 

Inforaation  cenaitta  of  facta,  facta  about  tha  *raal  aorld*  and 
ovanta  that  hava  happanad  in  it,  and  concluaiona  that  paopla  hava 
draan  about  it. 

faadaatatai  fact  fiz  7ba  parpaaa  af  oay  iafaraatiaa  ayafaa  if  ta 
itara  facts. 


An  airlinaa  inforaation  ayataa  atoraa  facta  about  airplanaa,  paaaan- 
gara,  flight  achadulaa,  faraa,  bootinga... 

A  clinical  pathological  laboratory  ayataa  atoraa  facta  about  pa- 
tianta,  doctora,  aachinaa,  taata  that  hava  baan  ordarad,  aaaplaa 
that  hava  baan  racaivad,  taat  raaulta,  OC  raaulta,  and  to  on. 

Eaaad  on  thaaa  facta  application  prograaa  can  aalact,  arranga  and 
praaant  uaaful  inforaation.  For  aaaapla,  a  litt  of  patianta  ordarad 
by  tha  «ard  and  root,  praprintad  labala  for  apaciaan  collactien, 
trand  analyaia  of  a  patianta*  glucoaa  laval  or  tha  parforaanca  of  a 
ShAC  20  (  a  laboratory  aachtna  ahich  can  aaka  aultipla  taata  on  ona 
blood  aaaplc). 

2-2  itit  yi!  61  l6f6Cfiiue:i  Sail!! 

Thara  ara  alaaya  at  laaat  two  uaara  of  any  inforaation  ayataa.  For 
organizational  inforaation  ayataaa,  thia  fact  ia  obvioua.  For  pri- 
vata  inforaation  ayataaa  •  an  individual *a  notaa,  aaaoriaa,  filaa, 
ate  >  wa  can  aaauaa  that  ha  playa  tha  rolaa  of  two  diffarant  uaara 
firat  whan  ha  atoraa  and  than  latar  whan  ha  ratriavaa  tha  inforaa¬ 
tion. 

fuadaaaatal  fact  #?i  Tka  aaara  af  aa  iafaraatiaa  ayataa  aafabiiab 
a  diaJafva  mita  aack  atkar  tkraapk  tka  atarad  facta, 

Uaar  1  will  input  a  fact  and  at  a  latar  tiaa  Uaar  2  will  aaka  uaa  of 
thia  fact.  (Saa  Figura  1.) 

Thia  principla  ia  to  fundaaantal  and  obvioua  that  it  ia  oftan  ovar- 
lookad,  but  tha  conaaguancaa  ara  vary  laportant.  If  Uaar  2  doaa  not 
undaratand  what  Uaar  1  ia  aaying  whan  ha  antara  hia  facta  than  Uaar 
2  cannot  aaka  uaa  of  than  or  oay  oiaintarprat  thaa  and  aay  taka 
aiatakan  actiona. 

Evan  in  tha  aaaa  diaeiplina  uaara  fraquantly  ai aundaratand  aach 
atharj  and  it  ia  a  coaaon  aaporianca  for  aoaaona  naw  to  tha  diaci- 
plina  to  go  through  a  laarning  curva  of  a  faw  waakt  or  oontha  bafora 
ha  undaratanda  tha  'jargon*  of  tha  diaeiplina.  Think  about  tha  tioa 
raquirad  to  bacoaa  a  doctor,  and  how  difficult  it  ia  for  a  doctor  to 
talk  tachnically  with  a  pationt. 
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Think  alto  about  ho*  aany  ordinary  tubjtctt  liht  tportt,  politics, 
rtlipien,  and  butinait  in  nhich  nt  oi sundarstand  ohat  anethtr  oayt. 

2-3  911  5tfii£dt9  »f 

N«l«:il  llSfluiB!  SiSlfCSff 

Tht'-t  art  aany  «ayt  Uttr  1  can  ceaaunicatt  facts  to  Ustr  2.  No  can 
sptak  to  hit,  tritt  a  ottsapt,  oakt  a  sign  or  tyabel  (likt  STOr), 
ust  body  tanguagt,  Horst  codt,  oritt  a  oathtaatical  feraula,  fill  in 
a  data  colltctien  fora,  typt  a  atssagt  at  a  coaputtr  ttrainal,  dra« 
a  coaputtr  floachart,  patnt  a  picturt,  ttc. 

btcaust  of  tht  aany  varittits  and  coapitxitits  of  coaaunication,  at 
stltct  only  ent  aay  to  concantratt  on  as  tht  basis  for  our  aork. 
This  it  coaaunication  in  natural  languagt  stnltncts  Caritttn  or 
vtrbal  ) . 

ftadaittfal  fact  #3/  diJ  cataaticat its  batattt  a  ottr  aid  at 
iafaraatiat  aystta  cat  bt  ragardad  as  a  aiapiifitd  fara  af  aatarai 
iatftafc  ttttaactf. 

(This  includtt  textual,  tabular  and  graphical  eeaaunicatien.  Those 
can  all  be  ti:prtsstd  tn  natural  language  by  exatining  each  part  and 
asking  the  autstien,  *Mhat  dots  this  otan?”) 

This  principle  uas  first  enunciated  (in  the  database  eorld)  in  the 
aiddle  I970's  by  Dr.  S.h.  Nijssen,  head  of  the  IflP  (International 
federation  of  Inforaation  frecestors>  aorkjng  group  on  databases.  He 
had  thi  novel  idea  to  regard  inforaation  systeas  not  at  aastive 
floucharts  of  prograe  logic  and  systee  processes,  but  as  a  vastly 
siapltfied  aodcl  of  huaan  eeaaunicatien. 

IDf  !!ffS  Isi 
8j£9yf£i2B  Its  PSDlll  PsBfl 

Nnen  hueans  coerunicate  in  natural  language,  they  hope  they  mil  be 
understood.  Unfortunately,  coaaunication  it  rarely  perfect.  Hhen  a 
aessage  is  subject  to  aultiple  interpretations  it  is  said  to  be 
aab 1 guout . 

Let's  look  at  seat  exaaples  of  aabiguity.  First  ae'Il  look  at 
Natural  Language  aabiguity,  then  at  inforaation  systee  aabiguity. 

<d>PSl9:il  kS2fiUIS! 

Consider  the  stateaenti 

■1T1N6  D06S  C«N  IE  DANGEROUS 

Nhat  dees  this  seen  ?  If  your  context  (oental  oodel)  is  canine 
hydrophobia,  then  it  oeans  dogs  ohich  bite  can  be  dangerous  to  you. 
On  the  other  hand,  if  your  context  has  the  huean  as  the  subject  then 
It  aight  aean  if  you  bite  the  deg,  it  could  be  dangerous  for  both  of 
you. 
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In  ,  tht  ttndir  e4  *  atttagt  «  •tntal  iaagt  of  the 

eituetion  «hich  i»  only  ioperfectly  referred  to  by  the  coaaunication 
aeteege.  In  order  to  recover  the  correct  aeaning,  the  roceiver  auit 
there  the  aaae  aental  iaage.  Otheraiee,  he  aakea  wrong 
*et«uaptions*.  Good  coaaunication  occuri  ahen  the  receiver  provides 
feedbecir  or  queries  the  sender  to  discover  the  context  intended. 

(b )  In4graet i gn  Syf|ea  Aftiggi^yj. 

Nom  let's  take  an  e»aaple  froa  a  record  keeping  systea.  Suppose  ae 
have  the  folloamg  data  on  a  fora.  To  keep  the  eiaaple  siaple  ae 
a:ll  liait  it  to  five  data  itaas.  (See  Figure  2.) 

hany  people,  particularly  prograaoert  and  designers  of  inforaation 
systeas,  tale  the  ‘data*  for  granted.  It's  obvious  that  this  table 
represents  data  about  doctors,  patients,  and  diseases. 

It's  also  vary  easy  to  design  a  data  file  to  hold  this  inforaation. 
The  data  aanageaent  systea  can  then  search  for  any  particular  doctor 
or  patient.  Sorts  can  be  used  to  report  by  patient  or  doctor  or 
disease  or  year  or  nationality. 

All  looks  aell  until  ae  ask  the  question  'But  ahat  does  it  aean  ?* 

It  could  aean  a  doctor  naaed  Salen  treated  a  patient  naaed  Lucius 

Ceaaodus  for  a  disease  naaed  Kalaria.  Or  it  could  aean  Salen  knev 

Coamodus  and  Coaaodus  suffered  free  Halaria  but  Salen  had  nothing  to 
do  aith  treating  the  disease.  Or  it  could  aean  Salen  wrote  about 

Coaaodus'  Halaria.  Or  even  that  Salen  treated  Coaaodus  but  it  «as 
Salen  who  had  Nalaria.  Or.... 

Siailar  questions  could  be  asked  about  who  was  a  Sreek  (Coaaodus  or 
Salen)  and  what  does  the  year  130  signify  in  relation  to  the  other 
data  eleaents. 

I  think  you  can  see  there  are  innuaerable  interpretations  aaong  the 
data  eleaents  in  this  siaple  table. 

The  consequences  of  this  aabiguity  are  that  a  user  of  the 
inforaation  systea  can  draw  the  arong  conclusions!  and  that 
redundant  and  inconsistent  data  aay  be  stored,  with  all  its 
attendant  costs  of  clean-up. 

feadaeeatil  Fact  Bdf  la  erder  far  eeaeb/feeas  ceeeeeicatiee  te 
take  Bat*  t*e  deader  aed  receiver  ef  the  aessafe  aart  abare 

the  ease  aeetal  aadeJ. 

If  you  are  developing  an  inforaation  systea,  you  should  stop  at  this 
point  and  ask  yourself,  *Have  ae  docuaented  the  coaaon  aental  aodel 
or  do  the  users  and  prograaoers  Just  assuae  they  understand  each 
other^*  Because  if  you  haven't,  you're  going  to  get  into  trouble. 
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2'S  jMg  irseiiitf  isz  its  Ptsiil 


Hh<t  «»  ntttf  it  t  aay  of  insuring  that  both  cessuni citing  psrtits 
Ihsrs  tht  Btsf  orntsl  sodtl.  Mhst  aould  liks  it  to  askt  thit 
•tntsl  sodtl  vitibls.  Thtn  ■*  can  docuntnt  thit  aodtl  and 
coaaunicatt  it  publicly  to  pravant  aabiguity  and  arrort. 

First  aa'll  look  at  tao  aathadt  paopla  hava  usad  to  analy:a 
tantancat.  Than  aa'll  choota  ona  of  thaa  for  docusanting 
inforaatien  structura. 

ii£yciu:f 

Ona  aay  of  analyzing  coaaunication  it  to  uta  English  graooar  to 
braak  a  tantanca  doan  into  its  alaaantary  parts  of  spaach.  This 
aathod  hat  an  advantaga  that  it  hat  baan  utad  for  canturxat  and  it 
taught  to  avaryona  in  school. 

Fo'  OKaapla,  avary  basic  English  tantanca  consists  of  a  subjact  noun 
phrasa  (NF)  and  a  varb  phrasa  (VP).  Syabolically,  aa  rapratant  tna 
tantanca  by  tha  forsula: 

S  ->  NP  ♦  VP 

Tha  noun  phrata  idantifiat  tha  subjact  of  intaratt,  and  tha  va'-b 
phrasa  tails  ahat  tha  subjact  doat,  it  or  hat  dona  to  it.  (Tha  arron 
aaant  'consists  of*  or  *it  produced  nhan*.) 

Lat  s  ta»a  an  axaapla. 

LUCIUS  COnnCDUS  NAS  TREATED  IY  SALEM 
FOR  HAlARIA. 


\  NP  *  Lucius  Cooaodut 

:  VP  ■  «at  traatad  by  Salan  for  Malaria: 


In  turn  aach  part  of  tha  tantanca  can  ba  daceaposcw  into  aaslla'’ 
parts  according  to  linguistic  rules  usad  by  every  spaaiar  of 
Engl  I sh. 
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S  ->  IIP  ♦  VP 

(noun  phrase  *  verb  phrase) 

NP  ->  DP  ♦  N 

(detereiner  phrase  *  t.oun) 

VP  ->  Aux  4  HVP 

(auxiliary  4  eatn  verb  phrase) 

HVP  ->  V  4  (NP)  4  (HAN) 

(verb  4  optional  noun  phrase 

4  optional  eanner  phrase) 

(b)!hj  SfeiSEllfislt 


Another  eay  o(  analyzing  coaaunicatien  is  to  use  the  object  -  role 
Bodel.  In  this  aodel ,  every  sentence  is  regarded  as  the  coabination 
o(  one  or  aore  objects  ehich  play  parts  (roles).  This  eodel  gives 
equal  Height  to  all  objects,  and  doesn't  single  out  any  one  of  thee 
as  the  ‘subject".  Also,  (this  eodel  requires  the  class  or  type  of 
each  individual  object  to  be  explicitly  naeed. 

The  object-role  aodel  breaks  a  sentence  doan  into  Its  eleaents  of 
Bearing. 

Let's  take  the  saae  sentence. 

LUCIUS  connoous  mas  treated  by  balen 
FOR  malaria. 

object  type  1  PATIENT 
object  1  Lucius  Coaaodus 

role  1  suffering 

object  type  2  DOCTOR 
object  2  Salen 

role  2  treating 

object  type  3  DISEASE 
object  3  Malaria 

role  3  afflicting 

This  aodel  has  several  advantages  over  the  graaaatic  structure 
aodel i 

-  It's  independent  of  English  language  specific  graaaar  hence  it's 
valid  for  all  speakers 

>  It's  Independent  of  the  order  of  the  objects.  (*Salen  treated 
Lucius  Coaaodus  for  Malaria*  is  recogniied  as  the  saae  fact.) 

>  it  coaaunicates  both  the  teaplate  froa  the  aental  aodel  as  aell  as 
the  particular  instances 
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Languagt  it  «  vthiclt  4or  cesaunicating  facta  and  craating 
undtratanding.  It  uaaa  vocabulary  and  graaaar  and  foatry  aa  a 
ceaplai  anvtlopt  for  carrying  ita  aaaaagt.  Whan  aa  naad  to  analyta 
tha  anvalopa  (tha  fora  of  tha  oaaaaga),  aa  aill  uaa  drinciglaa  of 
graaoar.  lut  ahan  tba  oaaaaga  itaalf  ta  iaportant,  ahan  aa  aant  to 
gat  at  tha  aatn  thougbta  or  tdaaa  that  paopla  aant  to  aipraaa  and 
that  lia  at  a  daapar  laval,  aa  aill  uaa  tha  objact  rela  aodal. 

Tharafora,  bacauaa  aa  ara  intaraatad  in  tha  contant  of  tha  aaaaaga, 
froa  noM  on  aa  aill  uaa  tha  objact  >  rola  aodal  aa  tha  baaia  for 
docuaanting  tha  aantal  nodal.  In  tha  nart  aaction  aa  aill  praaant  a 
feraal  dafmitior  of  tha  basic  ebjact-rela  aodal  and  aitansiens  to 
it  ahich  hava  provan  vary  uaaful  in  practical  appl icationa. 


2.6  If^lS 

Tha  population  tabla  ia  tha  graphical  aaana  for  illuatrating  tha 
objact  rola  aodal.  It  claarly  di at ingui ahas  bat«aan  tha  ganaral 
taaplata  and  tha  particular  inatancaa.  It  givas  tha  opportunity  to 
all  additional  inatancas  if  nacaaaary  to  confira  undaratandmg. 

(Saa  f igura  3. 1 

In  tha  population  tabla,  tha  objact  typaa  ara  in  circlas  connactad 
to  tha  rolas.  Tha  objact  inatancas  ara  in  tha  body  of  tha  tabla. 
Population  tablas  ara  aaallar  than  data  tablas  bacauaa  thay  ara  only 
aadr  for  alaaanta'y  aantancas. 

2.7  lltSSnULt 

A  aartanca  is  alaoantary  uhan  it  cannot  ba  dacoopoaad  into  aaallar 
aantancaa  aithout  loss  of  inforaation  or  introduction  of  aabiguity. 
Each  alaaantary  aantanca  contains  a  aingla  Indiviaibla  aassaga,  a 
aingla  fact  about  tha  *raal  uorld*. 

A  coapound  aantanca  convaya  oany  facts.  It  ia  coopoaad  af  tuc  or 
Bora  alaaantary  aantancas.  Tha  problaa  uith  coapound  aantancas  is  aa 
don't  aluaya  fenoa  ho*  thay  ara  put  togathar.  Tha  racaivar  deaan't 
alaays  fcnoa  tha  rulaa  of  coapoaition.  Thus  thay  ara  aora  auacaptibla 
to  incorract  intarpratation. 

Na  can  avoid  thaaa  problaoa  by  aluaya  dacoaposing  coapound  aantancas 
into  alaaantary  aantancas.  In  our  aiaapla  thara  ara  thraa  diffarant 
alaaantary  aantanca  typas.  (Saa  Figura  4.) 

2.t  ISOT  Prff£r^g^gn 

Finally,  aa  aantion  Fundaaantal  Fact  tS:  ISfiT  gf  (hg  gfgi.f 
l!!fe:§«il62  Ei!l  IS8  tuis  U  1C  I  SIintL  i6:8«l 
IciBceiUfic  Ssfitii 

Tha  inforaation  ayataa  can  anferca  corract  uaaga  and  pravant 
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pollution  tnd  nonttnot  only  H  it  kne«i  oil  0^  tht  rulto  tho 
inlerootion  ouot  eboy. 

Mt  hove  toon  that  nuotrout  interprototieno  ore  petaible  to  people 
■  ith  diMerent  eental  oodelt.  The  odoiniitrator  «ho  tpecifiet  the 
lyotea  toy  hove  one  set  of  oeoningo,  the  doctor  oho  queries  the 
inforeation  systee  say  have  another  ossuoption,  and  the  laboratory 
technician  «ho  enters  the  data  oay  have  a  third  interpretation. 

Anc  that  aeons  soaeday,  soaeone  could  oal'e  a  very  serious  oistatre. 
In  a  aedical  situation,  it  could  cost  a  life.  A  coaputer  can  do 
nothing  to  prevent  the  situation  until  it  is  provided  aith  the 
correct  Inforaation  Model. 

fill  iCillBLIlllifiDS  ICt  tSBtllT  UCtll  ItSlI  Lf  SCI  C8S22CIy 
i9:S£2  SBSCa  S69U!ICttB  SICUl  fiBStli. 


THE  INEORHATION  flOOEL 
3*1  Vha^  IS  fn  Inigraatipn  {Ifidcl 

An  Inforaation  Model  is  a  blueprint  for  understanding  a  user's 
inforaation  aorld.  It  is  both  an  abstraction  of  the  real  aorld  and  a 
prescription  for  any  coaputerised  inforaation  systea. 

An  Inforaation  Model  is  a  foraalised  object-role  eodel  .  It  contains 
specification  of  all  object  types,  fact  types  (and  roles)  and 
constraints  organiied  in  a  seaantic  network.  It  docuaents  the  user's 
aental  aodel . 

3.2  Wh^  MflBlB 

The  aain  purpose  of  an  inforaation  oodel  Is  to  docuaent  an 
understanding  of  the  real  world  in  order  to  perait  unaabiguous 
coaaunication  to  take  place.  When  two  coaauni cat i ng  partners  share 
the  saae  oental  inforaation  oodel,  then  they  both  interpret  the 
coaaunication  in  the  saee  way. 

A  second  iaportant  purpose  of  the  Inforaation  Model  is  to  organize 
locally  discovered  facts  into  a  global  network,  showing  how  they  are 
related  to  previously  understood  inforaation. 

3.3  CecEtBlf  Si  lilt  Icisrfiiisc  SsSil 

There  are  two  kinds  of  object  types  shown  in  the  Inforaation  Model: 
entities  and  syabols. 

(Refer  to  Figure  S  to  see  eiaaples  of  these  syabols.) 


Cclily  ItBI  *  A  solid  oval  representing  all  possible  instances  of 
soae  real  world  objects  or  concepts. 
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Eiaapltii  Doctor,  Politnt,  Troototnt,  lid-Aotignotnt ,  Iptciain,  ttc. 


IxCf  *  *  doihtd  circlo  rtprtttnling  tho  tot  o4  •yabels  ahicfi 
can  raftr  to,  or  idantHy  antitiaa. 

Eiaaplta:  Oocter-Nioa,  fatiant-Nr,  Traataant-Cotfa. 

In  gantral,  tbart  it  net  a  ana  to  ana  ralatienahip  bataaan  ayabolt 
and  antitias.  You  aill  Itnd  aoaa  antittat  with  aara  than  ana  ayabol 
used  to  ra^er  te  thaa  I4er  a<aapla  Docter>naae  and  Dactar-nuabar ) , 
and  aoaa  antitias  nith  non-unigua  ayabolt  tior  aiaapla,  thara  aay  ba 
aavaral  unconaciaus  'John  Dots*  in  tha  aaargancy  reoa.),  and  aoaa 
antitias  and  concapts  aith  no  allicially  racognisad  idanti4ying 
sybaolt  l4or  aiaapla,  a  lab  tachnician'a  visual  inspaction  b4  a 
tasting  aachina  er  tha  inioraal  group  e4  aorfcara  playing  cards  at 
lunch) . 


SyBltEE  '  *  diractad  1  ina>sagaant  connecting  tae  Entity  types, 
pointing  4roa  the  subtype  to  the  aupartypa.  All  instances  e4  the 
subtype  ara  autoaatical ly  instances  o4  tha  aupartypa,  and  all 
propentias  o4  the  aupartypa  are  inherited  by  the  subtype. 

For  atavola,  all  Doctors  are  Health  Cara  Personnel,  and  share  their 
prspirtias,  such  as  concern  4or  patients  health,  assignsent  to 
hospitals,  state  licensing,  ate.  In  addition,  doctors  have 
properties  not  possessed  by  the  supertype,  4or  aiaapla,  the 
authorisation  to  prescribe  traatsents. 

Frequently,  subtype  relationships  occur  in  Faeilias.  This  reFlects 
the  huear  aind  at  aorlr  (liSSiixiSfi  hf  antitias.  In  Figure  S 
there  are  t«e  faailias  headed  by  PERSON  and  by  TEST. 


Pelf  -  the  part  played  by  an  abject  type  in  a  ralataenship.  Each 
object  in  the  relationship  plays  a  role. 

For  aiaapla,  if  a  laboratory  technician  perferas  a  test  an  a 
speciaen,  then  the  tao  rales  are  parferatng  and  tasted.  The 
technician  is  the  perferatng  technician  and  the  speciaen  is  the 
tested  speciaen.  If  the  technician  later  does  a  quality  check  on  a 
test  result,  then  that  technician  is  the  checking  technician. 

•  There  are  tmo  kinds  of  fact  typesi  ideas  and  bridges. 


iBti  llfBt  '  A''  inforaation  bearing  relationship  betneen  tao 
Entity  types.  Each  Entity  type  plays  a  rale  in  the  relationship.  The 
rales  are  placed  in  boies  neit  to  the  corresponding  Entity  types. 
This  relationship  can  be  read  in  both  directions. 

For  aiaapla,  ^A  Doctor  (is)  treating  a  Patient,  or  the  Patient  (is) 
treated-by  a  DOCTOR. 


IridfiS  IXCf  ~  is  *  naaing  relationship  connecting  an  entity  type 
Hith  a  tyebol  type.  A  bridge  repreaents  an  arbitrary  naaing 
convention. 

For  evaeple,  PERSON  aith  SSN. 


EfiCflCiiSl  *  is  a  restriction  on  the  allOHable  states  of  the 
tnforaation  base  and/or  on  transitions  betaeen  then. 

A  constraint  is  a  rule  el  behavior,  either  a  business  rule  such  as  a 
patient  aay  not  occupy  aore  than  one  bed,  or  a  coaaonly  accepted 
natural  law  such  as  babies  aay  be  born  only  to  leaale  patients. 

i!9** 

An  Inloraation  Model  is  constructed  by  connecting  together  the 
flfoentary  pieces  el  inloraation  discovered  during  analysis.  These 
eleaentary  pieces  do  not  have  to  be  derived  in  any  given  way.  They 
can  be  used  as  they  are  lound,  ohen  they  are  leund,  Iren  any  source. 
This  lleKibility  exists  only  ahen  the  pieces  are  truly  eleaentary. 

The  Inloraation  Model  is  constructed  graphically,  usually  on  large 
sheets  oi  paper.  First  objects  and  their  subtype  connections  are 
drawn.  Then  ideas  and  bridges  are  connected  to  the  objects.  Finally 
constraints  are  drawn  connecting  objects  and  roles. 

As  the  diagraa  is  constructed  its  correctness  and  oeaning  are 
constantly  checked  by  verbalising  the  syabolt  in  English  and  by 
using  population  tables. 

There  are  two  aethods  ol  gathering  the  inloraation  lor  asking  the 
diagraa:  the  guru  aethod  and  the  archeology  aethod.  The  guru  oethod 
involves  interviewing  subject  oatter  experts  whose  knowlege  is  so 
thorough  that  recourse  to  other  sources  is  not  necessary.  It  is  the 
easiest  and  oost  coaaon  technique.  The  archeology  aethod  involves 
exaaining  reports,  ceaputer  listings,  policies  and  procedures  and 
other  docuaents  to  extract  the  eleaentary  facts  and  build  a  coherent 
inloraation  aodel  Iron  then.  It  is  ouch  aore  dillicult  and  slow. 

3.:  IcltEvltsica 

Interviewing  is  the  aest  coaaon  technique  used  in  the  initial  stages 
el  building  an  Inloraation  Model.  Users  tend  to  be  at  ease 
explaining  in  English  the  inloraation  they  need,  the  objects  el 
their  environaent  and  the  rules  el  inloraation  behavior.  Later  in 
the  analysis  they  begin  to  understand  the  syabolic  language  el  the 
Inloraation  Model  diagraa  and  can  participate  in  their  construction. 

During  the  initial  stages  a  prelessional  Inloraation  Analyst  is  very 
helplul  in  guiding  user  diseusssiens,  keeping  thee  locused  on  the 
subject  and  explaining  the  techniques. 


IPSTl 


11 


{updated  Feb  14,  ISBSI 


Tht  aott  iaportant  ^utttiont  he  etks  during  the  inlervitHi  ere 


*Tell  ec  about  ...* 

*Nhat  does  thii  aean 

Thai*  guestiene  elicit  Cngliah  replies  ahich  are  rich  in  seaantic 
relationships  (facts)  about  objects.  The  inferaation  analyst  then 
breais  do«n  sentences  into  eleaentary  facts  and  diagraas  thee. 

CiisEif  Si  IsitiKiff  !!eiff 

*I  ncsd  to  keep  inferaatien  about  patients  and  doctors  and 
laboratory  tcsts. 

*Nhen  a  patient  is  adaitted  to  the  hospital  ae  collect  basic 
dsaegraphic  inforeation  such  as  his  naae  and  social  security  nuober 
and  se:-  and  year  of  birth.  Me  also  record  his  date  of  adaission  and 
later  his  date  of  discharge. 

*Fatients  are  treated  by  one  doctor.  Noaever,  they  aay  also  be  seen 
by  other  doctors,  aho  aay  give  advice.  Only  the  patient's  priaary 
doctor  aay  prescribe  laboratory  tests.  And  a  patient  oust  be 
assigned  a  priaary  doctor  before  he  can  be  seen  by  ether  doctors. 

*A  doctor  say  order  tests  for  a  patient.  There  are  various  kinds  of 
test  he  aa>  order,  fach  test  is  perferaed  by  a  lab  technician.  A 
doctor  could  order  several  different  kinds  of  tests  for  a  patient  on 
the  save  day  and  aay  order  the  saae  test  to  be  perforaed  aore  than 
once. 

*The  lab  technician  ca^’ries  out  the  tests.  Lab  technicians  and 
doctors  are  both  health  care  personnel,  but  no  one  can  be  both  a 
doctor  and  a  lab  technician.  The  lab  technician  perfores  patient 
tests  and  quality  control  tests  on  his  equipaent.  These  are  the  only 
kinds  of  tests  allowed,  lose  tests  are  run  aore  than  once  and  the 
results  are  judged  by  the  technician  aho  writes  ceaeents  on  the 
reports.  Different  test  results  for  the  saae  requested  test  are 
distinguished  by  sequence  nuabers. 

"Each  test  can  be  perforaed  by  only  one  lab  technician,  be  ordered 
by  only  one  doctor  and  be  for  only  one  patient.  Nhile  it  is  possible 
for  doctors  or  lab  technicians  to  be  adaitted  as  patients,  our 
hospital  does  not  perait  thea  to  order  or  perfora  tests  for 
theasel ves. 

"Furtheraore,  if  a  doctor  is  adaitted  as  a  patient  he  aay  net  treat 
hiaself . * 


3.7  Ihg  ICiPlftllfiS  BlHCtf 

The  results  of  this  interview  are  docuaented  in  an  Inforaation 
Model  diagraa.  (lee  Figure  9.1  Flease  note  that  this  aodel  is  only 
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for  illuttration.  It  is  too  siopit  to  bt  rtslistic.  In  a  rtal 
projtct  sore  analysis  Mould  taka  plact  and  Many  iaprovaatnts  aadc. 

An  inforaation  aodal  diagrar.  is  a  pictorial  raprasintation  of  the 
problta.  It  is  procissad  by  tha  right  half  of  tha  analyst's  brain. 
This  activity  coaplaaants  tha  intarviaaing  or  varbal  staga  of 
inforaation  analysis  which  draws  aostly  on  tha  laft  half  of  tha 
brain.  Tha  laft  half  analysas  tha  inforaation  and  undarstands  tha 
alaaantary  piacas  of  aaaning;  tha  right  half  synthasas  tha  facts  and 
undarstands  tha  organization  of  knowladga. 

3.8  hfti  Swiss 

Hata  rulas  ara  guidalinas  for  tha  corract  and  consistant 
construction  of  an  Inforaation  Modal.  Thay  raprasant  accuaulatad 
knowladga  about  knowladga  tnginaartng,  and  thay  halp  tha  dasignar  of 
an  inforaation  aodal  datact  fuzzy  thinking  and  construction  arrors. 

Soaa  araaplas  of  aata  rulas  ara  tha  following: 

*  no  isolatad  objact  typas. 

avary  subtypa  faaily  has  ona  coaaon  ancastor. 

>  avary  rola  aust  ba  connactad  to  ona  and  only  ona  objact  typa. 

*  in  any  constraint  or  guary  which  involvas  a  coaparison,  tha  rolat 
coaparad  oust  connact  to  tha  saaa  objact  typa  or  a  subtypa  and 
supartypa  in  tha  saaa  faaily. 

-  avary  fact  typa  has  a  siapla  uniguanass  constraint;  if  not,  tha 
fact  IS  not  alaaantary  or  an  objact  typa  has  baan  oaittad. 

*■  in  any  constraint  or  guary  tha  path  specification  aust  ba 
unaabi guouE . 

3*9  CiiUc&ilsc  Iflsttc  Sslt  IStf  DkilU 

Many  baginnars  initially  hava  trouble  distinguishing  between  a  role 
and  an  objact.  It's  coaaon  to  sea  a  aodal  with  two  objacts  DATE  of 
adoission  and  DATE  of  TEST.  In  raality  thara  is  only  ona  objact 
(DATE)  and  it  plays  two  roles:  (DATE)  of  adoission  of  (PATIENT)  and 
(DATE)  of  (TEST). 

Usa  of  distinct  objact  typas  for  distinct  concapts  and  coaaon  objact 
typas  for  coaaon  concapts  aliainatas  radundancias  and  provants 


For  tiaaple,  the  guary,  *6ive  ae  a  list  of  all  PATIENTs  whose  DATE 
of  ADMISSION  aguals  their  DATES  of  discharge*  is  a  sansibla  guary. 
It  involves  the  coaparison  of  the  coaaon  objact  typa  DATE. 

On  the  other  hand,  tha  guary,  *tiva  aa  a  list  of  all  PERSONS  who 
ware  bern>in  tiie  saaa  TEAR  as  their  SEX  is  clearly  nonsensical.  It 
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invelvtt  tbi  illtgal  ceapariten  si  distinct  ebjsct  types 
3.10  £11  ASSffS  fil!!l  fbfiSS 


The  Inlorsation  Model  bas  the  interesting  and  uselul  characteristic 
that  all  logical  access  paths  to  any  piece  el  inleraatien  are  ehean. 
Unlike  ether  aetheds,  access  paths  are  never  ellainated  ler 
•elliciencv*  reasons. 

LttCLt!£ll  BVt:x  Uy&Iytl  t  V.  V.  Illtl  ItCSUBtl 

Itf  IsieifiUsc  CfiStli 

Let's  look  at  three  cases: 

*  Itfiil  ByS^itf  *  puh'y  path(s)  is  unaabigueus;  this  guery  cakes 
sense. 


*Eive  ae  a  list  el  all  hATlENTs  treated-l 
by  DOCTOR  John  Kildare*.  : 


:*S;vc  ae  the  VALUES  el  all  TEST*ltESUlTS  : 
;ior  all  TESTS  lor  MATIEMT  aith  NAhE  1 
ihary  C.  Stewa-t*.  ! 


**  BVfClfS  *  the  query  path  intended  is  unclear 


I'Sive  ce  a  list  el  all  fATIENTs  and  their! 
iDOCTORs*.  This  could  aean:  \ 


a)  PATIENT  treated-by  DOCTOR 

b)  PATIENT  also-seen-by  DOCTOR 
C)  or  both 

d)  or  even  seae  longer  path  involving 
interaediate  objects 


itBBIilBIt  BBlCiH  -  there  is  no  path 


I'Sive  ae  a  list  el  all  PATIENTS  aho 
lhaven't  paid  their  bills*. 


To  ansaer  this  question  you  oust  oitend  the  Inleraatien  Model. 

Queries  are  auch  easier  to  leraulate,  discuss,  revise,  understand, 
IP6T1  14  lupdated  Feb  14,  1*651 


and  agrtt'upon  «h«n  uitng  tha  Inferaatien  Modal  than  alth 
traditional  prograa  docuaantatien. 

5**^  Sbit  ESDIlSliDlS 

Conatrainta  art  4oraali<ad  knealadga  rulaa  about  natural  laaa  or 
ergani :ati onal  policy.  Thay  ara  tha  rulaa  o4  bahavior  ahich  ara 
an4orcad  ahan  in4oraation  ia  addad  to  er  dalatad  frea  tha 
inforaation  baaa.  Thay  ara  alao  tha  conditiona  ahich  hold  aaong  all 
inforaatton  4acta  in  tha  baft.  Thay  guarantaa  tha  buhUty  , 
uaa4uinaaa,  and  conaiftancy  e4  tha  inforaation.  With  conatrainta  no 
uaar  can  accidentally  or  dalibarataly  tntroduca  nenaanaical  or 
inconaiatant  inforaation. 

Traditionally,  chacka  for  tha  corractnaca  of  tha  inforaation  Oaaa 
hava  baan  buriad  daap  inaida  prograaa,  unraadabla  and  unvartf labla. 
Thia  aituation  haa  lad  to  rathar  haphazard  conatraint  anforcaaant. 
Tha  aaount  of  conatraint  chocking  haa  tandad  to  ba  a  function  of  tha 
axparianca  of  tha  prograaaar,  tha  aaaa  of  prograaaing  tha 
constraint,  and  aaount  of  tiaa  givan  to  tha  projact. 

Usara  typically  aaauaa  aora  conatraint  chocking  in  thair  data  than 
thara  raally  la.  Hhan  converting  a  typical  production  ayatan  to  ona 
■ith  anforcad  conatrainta  thay  ara  aaatad  and  diftrasaad  at  tha 
nuatar  of  arrora  diacovarad  in  thair  production  data. 

3.12  Sssf  Cgaagn  CfinfJ:r|in|f 

Inforaation  Pnalyata  ara  unigua  in  racognizing  tha  iaportanca  of 
conatrainta  and  in  davaloping  oathoda  and  notationa  for  aaaifting 
uaara  in  finding  and  apacifying  constraints. 

It  turns  out  that  in  a  typical  Inforaation  Medal,  construction 
effort,  aoaa  SOX  of  tha  constraints  uncevarad  fit  into  a  aaall 
nuabar  of  already  recognized  catagorias. 

A  fa«  of  the  cooaonly  occurring  constraint  types  and  anaaplaa  aret 

-  subtype  exclusion  -  too  or  aora  subtypes  are  autually  exclusive. 
(A  TEST  aay  ba  either  a  PATIENT-TEST  or  a  OC-TEST,  but  never  both.) 

-  subtype  total  *  the  union  of  tne  er  bore  subtypes  aguals  tha  total 
supartypa.  (A  PATIENT-TEST  and  a  OC-TEST  are  tha  only  kinds  of  TEST) 

-  role  uniqueness  -  ovary  fact  in  tha  Inforaation  Medal  has  one  or 
aora  roles  unique.  (A  PATIENT  is  traatad-by  a  unique  SOCTOS.  A  TEST 
is  uniquely  for  ana  PATIENT.) 

-  role  subset  -  tha  population  of  rolal  oust  ba  a  subset  of  the 
population  of  rela2.  This  is  a  sat  algebraic  feraulation  of 
constraints  involving  tha  concepts  of  'before*  and  'ioplias*. 
ilafora  a  PATIENT  can  ba  seen  by  ether  BOCTORs,  ha  oust  first  ba 
treated  by  his  ean  DOCTOR.) 
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*  joint  uniqutnttK  -  tht  coobinatien  of  too  or  ooro  rolot  uniqutly 
tfotaroinot  an  ebjoct.  H  you  knoo  tha  PATIENT,  and  tht  DATE,  TINE, 
and  KIND  of  TEST,  tbon  you  knoo  ohich  PATIENT*TEST.  (On  tho  othor 
hand  OC'TEST  oust  ha  dotaroinod  in  a  diKarant  oay  bocauta  no 
patiant  if  Invol vod. ) 

*  aquivalanca  of  path  ■*  too  diffaront  pathf  Iroo  objoct  typa  1  to 
ebjact  typa  2  piva  tha  laaa  raault.  (Tho  DOCTOR  troatinp  tha  PATIENT 
Oust  ba  tha  aaaa  DOCTOR  ordarinp  tha  TESTt  (or  tha  PATIENT.) 

3.13  ISO 

Racantly  tha  Intarnational  Standarda  Orpanization  eonductad  a  ttudy 
en  tha  'Coneaptf  and  Toroinolopy  (or  tna  Concaptual  Schaaa.*  ISOa 
Imfy  approach  if  Offantially  tha  Inforoation  Nodal  dffcribad 
ha'a. 


4.  DATABASE  ENSINCERINS 


Aftar  tha  in(oraation  probloa  haf  baan  analytad,  tha  nait  atop  it  to 
datipn  tha  databaaa.  A  pood  databaaa  daaipn  oUl  ba  oaay  to 

undaratand,  oodify  and  onhanca,  hiph  m  parforoanca,  aocura  and 
raliabla,  oaay  to  uaa,  and  aaat  tha  noada  o<  ita  uaara. 

I&t  Gill  CbSsI 

Tha  dafigna*-  of  a  databaaa  oiproaaaa  hia  daaipn  in  taraa  o(  a  data 
aodal.  A  data  oodal  la  a  oap  of  tha  data  orpaniiod  into  a  natoork  of 
racord  typaa.  Each  rocord  typa  containa  ona  or  oora  naaad  data 
olaaanta.  A  data  olaoant  ia  tha  aaallaat  addroaaabla  vnit  oithin  a 
databaaa.  Solid  linaa  link  tepathar  data  olaaanta  in  di(farant 
racord  typaa,  or  connact  (roo  *eut  of  tha  bluo*  into  a  data  oloaant. 
Thaaa  patha  into  and  through  a  data  oodal  alio*  tha  uaar  to  find  tha 
data  ha  naada.  Advancad  data  oodala  alao  contain  data  intaprity  con- 
atrainta.  (Saa  Fipura  6.) 

4*2  Nhy  Nffpfd 

Tha  databaaa  uaar  haa  aavaral  roaaona  (or  noadlnp  a  data  oodal  aa  ha 
plana  hta  uaa  of  tha  data. 

Hia  float  (undaaanta)  nood  ifl  to  kno«  tha  naaaa  of  tha  data  olaoanta 
•hich  ara  docuaantad  in  tha  data  aodal  flo  ho  can  tall  tho  coaputar 
■hich  data  to  accaaa. 

(Dacauaa  ao  oany  data  olaaanta  hava  tha  taao  (oraat,  it  ia  not 

poaaiblo  to  diatinpuiah  thaa  juat  on  tha  baaia  of  thair 
ropraaantation.  Conaidar  (or  oiaapla  tho  data  0l/05/t4.  Ia  thia  tha 
Data  of  adaiaaian,  tha  DATE  fl(  diacharpa,  or  tha  DATE  of  birth  ?> 

Sacondly,  tha  databaaa  uaar  noada  to  kno«  ohich  data  olaaanta  ara 
orpaniiad  topathar  into  tha  tana  rocord  typa.  Dacauaa  float  coaputar 
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l«ngu«g»s  accist  date  ena  rtcerd  typt  at  a  tiat,  it‘«  iapertant  to 
knoM  ahich  data  alaaanti  aill  ba  availabit  tegathar. 

Thirdly,  tha  databata  uaar  naada  to  kno«  tha  aaaantic  paths  through 
tha  data  aodal  in  ordar  to  ratriava  data  ralatad  ^n  |  flvtQ  BIX 
tha  data  ha  alraady  has. 

(Thasa  ara  not  physical  paths  such  as  tha  CODASVL  nataork  structura, 
but  ara  tha  basic  undarstanding  o4  aaanings  naadad  to  ask 
intalligant  guastions.) 

It  is  in  this  last  aspact  o4  tha  naad  to  knoa  tha  path  or  paths  to 
ralatad  data  that  tha  usar  is  liktnad  to  a  navigator  and  tha  data 
aodal  to  a  aap.  In  planning  coaplar  data  applications,  tha  data 
aodal  aap  is  an  indispansibla  tool  for  tha  data  navigator. 

4.3  Th| 

Tha  coaputars  databasa  aanagaaant  systaa  (dbas)  also  naads  to  knou 
tha  data  aodal.  A  dascription  of  tha  data  aodal  is  arittan  in  a 
ceaputar  syntax  cal  lad  a  databasa  schaaa.  Tha  dbas  raads,  chacks  and 
safaly  storas  a«ay  tha  databasa  schaaa.  Than  it  usas  tha  schaaa  to 
plan  bom  to  organira  and  ratriava  tha  data  afficiantly,  and  to 
guarantaa  its  corractnass. 

Hhanavar  tha  usar  asks  for  an  updata  or  ratriaval,  tha  dbas  consults 
tha  schaaa  first  bafora  accassing  tha  data.  In  this  aay  it  can  carry 
out  tha  usars'  coaaands  corractly  and  afficiontly. 

*•*  Siiisifst  iseltetsliUsc 

Efficiant  iaplaaantation  of  largo  databasas  on  prasant  day  coaputing 
aachinas  raquiras  a  groupad  data  aodal.  Tha  data  oodal  is  foraad  by 
grouping  togathar  tha  concopts  of  an  inforaation  Nodal  into 
officiant  racord  typos,  data  olaaants  and  thair  connactions. 

(An  ungroupad  Inforaation  Nodal,  though  aora  saaantically  rich,  aora 
datailad,  and  aora  flaxibla,  raquiras  advancad  coaputor  architoctura 
for  officiant  iaplaaantation. ) 

Tmo  cost  charactaristics  of  today's  coaputars  ara  iaportant 
considarations  for  tha  grouping  algoritha: 

*  Storing  largo  asounts  of  data  is  oipansivo.  Coaprassing  data  to 
raduca  redundancy  dacraasas  storage  costs  by  SOX  or  aora. 

*  Accassing  a  block  of  data  froa  a  storage  device  and  bringing  it 
Into  sain  aaaory  is  a  slos  and  oipansiva  process.  Hoaavor,  reading 
tha  data  olaaants  froa  tha  block  once  it  is  in  aain  aaaory  is  fast 
and  cheap.  Nance  data  olaaants  ahich  ara  used  togathar  should  be 
groupad  tegathar  into  tha  saaa  data  block  to  raduca  access  costs. 
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<•5  Itt  (cfiveisa  fiUe:itt!£ 


In  tht  prtvieus  ■•etien  ••  tfitcutttd  that  too  4»m  data  altaanta 
grouptd  tegfthtr  raault  in  an  inalficiant  tfaaign.  On  tha  othar 
hand,  it  is  also  •all  Itnean  that  too  aany  data  alaaants  frouptd 
tetathar  rasult  in  radundant  steraga  and  ceaplan  pregraas.  Hhat  aa 
naad  is  an  intaraadiata  aaount  al  grauping  amch  is  Just  right. 

Tha  4ull  grouping  algeritha  also  includas  stops  far  chocking  tha 
Irforaation  fiodal  4or  consistancy  and  ra^arancoabiltty,  for 
salacting  soot  tuning  options,  for  grouping  tha  constraints,  and  for 
constructing  tha  full  data  aodal.  This  algaritha  is  taught  in 
Inforaation  Analysis  saainars  and  has  boon  caaputariiad  and 
iaplaaantad  for  about  a  half  a  do:an  currant  databasa  aanagars. 

Haro's  tha  siapla  salaction  critarion  usad  in  tha  grouping 
al gor itha: 

for  aach  antity  class:  lilggt  Ifil  ILBUClCa  8QU  aiCIttU 
IlSSlf  Xiluad  iicii. 

This  siapla  grouping  rula  ganaratas  racord  typos  ahieh  satisfy 
afficiancy  and  oast  of  usa  critaria. 

>  A  fact  is  storad  only  anca  (nen-radundancy ) 

•  A  fact  is  storad  in  a  fitad  location  (pradictabi 1 ity) 

*  Evary  data  alaaant  is  dataramad  by  *tha  kay,  tha  ahola  kay  and 
nothing  but  tha  kay*  ineraaliiation) 

>  No  uastad  storaga  space  (lo«  cost) 

In  short,  an  alagant  oathod 

Bslilignitie  16  keiu  CLegutme 

Logic  prograaaing  using  languagas  such  as  AR0L06  and  LISA  is  a 
rapidly  advancing  na«  stylo  of  problaa  solving.  Instaad  of 
opacifying  tha  flo«  of  pracass  as  in  a  convantional  prograaoing 
language,  tha  prograasar  spacifias  tha  ralationships  or  prodicatas 
uhich  hold  and  rulas  for  dariving  na«  knoMladga. 

Just  lika  in  tha  databasa  aorld,  it  is  nacassary  to  first  analyca 
the  coBBuni cation  and  build  an  inferoatian  oodol  of  tha  inforaation 
probloB.  lafora  logic  and  daduction  can  ba  appliad  aa  oust  first  be 
sura  that  bo  undarstand  ahich  problaa  aa  ara  solving. 

Tha  prodicatas  ahich  art  daclarad  to  tha  progras  ara  tha  alaaantary 
santancas  or  groups  of  alaaantary  santancas  froo  tha  inforaation 
aodal.  Hhan  grouping  tha  santancas  tha  saaa  rula  as  bafera  is  usad 
aith  tha  addition  that  tha  total  rola  constraint  is  obsarvad:  only 
singla  valuad  facts  ahich  art  connactad  to  tha  objact  aith  a  total 
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rolt  constraint  art  greuptd  togtthtr.  In  ttiis  way  ■e~calltd  aissing 
valuas  art  avoidtd. 

.cp  5 

4*7  Uc  2  S(!!CSi  ArghllttUCt 

So  far  Mt'vt  talktd  as  H  tach  databast  systta  has  only  ona  schaaa. 

And  aha  la  in  fact  aany  do,  aodarn  databasa  oanagaaant  it  avelving  to 
a  thraa  schaaa  architactura.  This  naad  «as  first  racogniiad  by  ANSI. 

dhy  Thrgff  S£hfa|s 

Databasa  systaas  aith  ona  schaaa  suffar  froa  lack  of  data 
indapandanca.  Each  usar  has  tha  taaa  via*  of  tha  data.  If  any 
change  it  aada  to  the  data  oodal ,  than  all  users  Mill  have  to 
change. 

In  a  tMo  schaaa  anvironaant  users  have  aora  data  indapandanca  and 
protection.  Tha  databast  schaaa  can  changa  toaauhat,  and  tha  users' 
subschaaas  stay  tha  saaa.  They  continue  to  use  and  via*  data  in 
their  preferred  subschaaa  aodel. 

In  a  thraa  schaaa  anvironaant  tha  databasa  schaaa  is  replaced  by  a 
conceptual  schaaa  ahich  defines  tha  NHAT  of  tha  data  problaa,  one  or 
aora  internal  schaaas  uhich  define  HON  tha  data  is  oast  efficiently 
stored  and  retrieved,  and  one  or  oora  oitarnal  schaaas  ohich  define 
HOK  the  usar  groups  prefer  to  view  and  access  thair  data.  Tha 
conceptual  schaaa  is  created  autoaatically  by  tha  grouping 
algoritha.  (Sea  Figure  7.) 

A  databasa  systaa  anginaarad  uith  a  3  schaaa  architecture  provides  a 
nuabar  of  direct  and  indirect  benefits  to  its  users.  Tha  direct 
benefits  are 

-  Any  user  can  altar  his  preferred  viaa  of  tha  data  described  in  the 
external  schaaa  aithout  affecting  any  other  user. 

>  A  databasa  engineer  can  coaplataly  raorganira  tha  physical 
databases  described  in  tha  internal  schaaas  nithout  affecting  a 
single  line  of  user  source  coda  or  interactive  procedures.  In 
particular,  tha  database  engineer  can  tuna  tha  physical  databasa 
structures  follewing  iapleoentation. 

•  An  enterprise  adainistrator  can  turn  constraints  on  or  off  and  can 
enlarge  his  data  aodel  described  in  the  conceptual  schaaa  to  support 
nea  functions  nith  no  effect  on  ovisting  prograas,  interactive 
procedures,  or  data  organisation. 

Secondary  benefits  include  the  follooing: 

•  Less  fear  of  change,  because  systea-Hide  correctness  is  guaranteed 
by  the  conceptual  schaaa. 

•  Sealler  update  prograas,  and  ouch  loss  devolepaont  cost. 
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-  Clt*>n«tion  el  garbage  4ree  tht  data  with  cenitraint  anforcaatrit 


*  Aveidanca  o4  leck-in  to  currant  ghyaical  dbaa  tachnelogy. 

Figure  •  ahoMa  the  atepa  4rea  preblea  recegn'tien  to  3  acheea 
iapleaentation. 


S.  CONCLUSION 

s-1  Stil  HszlS  fsefcicsst 

Since  1976  a  group  e4  Inforaation  Cenaultanta  have  been  applying  the 
concepts  e4  natural  language  in^eraatien  analyaia,  infereatien  aodcl 
conatructio'  and  data  eodeling  to  large,  real  eerld  in^ereation 
aystea  projects.  In  these  nine  years  they  have  helped  sore  than  120 
clients  develop  eodern  e^lective  in^oreation  aystees.  In  several 
cases,  the  clients  had  spent  5  years  and  as  eany  Billion  dollars  in 
traditional  analysis  aethods  eithout  results. 


During  this  aerk,  the  natural  language  basis  of  factual  Infereation 
ceasunicatien  end  the  object  •  role  aodel  have  been  tested 
successfully  in  about  20  languages,  including  Indo*^Eurapean, 
Setitic,  and  Oriental  languages.  This  practical  experience  has  giver 
us  confidence  in  the  fundaeental  validity  of  eur  linguistic 
analysis. 


5*2  fiiiiEiic  dcelUitiesi 

Large  scale  application  of  the  Infereation  Analysis  eethedology  has 
been  to  coeputerited  database  application  systees  for  oanufactu*'ing, 
service  and  governaental  organisations.  Eiaeples  froa  various 
industries  include  a  clinical  pathological  laboratory  systea,  an 
engineering  docueentat i on  and  configuration  eanageaent  syster,  a 
coebined  turbine  engineering  design  end  drauing  data  base,  a  health 
physics  records  keeping  systea  for  a  nuclear  utility,  a  petroleua 
exploration  database,  end  the  entire  application  portfolio  for  t«o 
insurance  coapanies. 


5-3  ChillEltEilUSI 

The  aost  striking  Characteristics  of  these  srojects  are  the 
increased  user  understanding  of  his  reguireaentst  his  increased 
participation  in  end  ceasitaent  to  the  requireaents  specif icatien 
efferti  and  his  satis'action  uith  the  final  iapleaentation. 


Typically, 

training 

Thereafter 

•ork. 


e  user  can  beceae  proficient  aith  a  fee  days*  classroee 
and  learning  experience  in  a  project  teas  onvirenaent. 
,  he  takes  a  direct  hand  in  the  analysis  and  docuaentation 


In  these  efforts,  Inforaation  Analysis  has  found  aere  requireaents, 
and  specified  thee  aere  precisely  than  traditional  analysis 
aethods,. ..seeetiaes  draaatically  aere.  As  a  result  the  iapleeented 


«pplicat>ont  arc  core  coaplctc,  have  facer  errora,  and  require  leci 
prograceing  recork  both  during  initial  cenitruction  and  after 
iapleaentation.  Oatabaae  design,  previously  eitrcacly  difficult,  has 
becoec  core  routine. 

Data  processing  professionals  report  greater  productivity,  users 
receive  sore  flcKiblc  and  coeplcte  solutions,  and  aanageaent  secs 
better  cost  and  schedule  control. 

fiEfilisifeiiiiy 

But  Inforaatton  Analysis  is  not  liaited  Just  to  application 
devclopaent.  It  has  been  applied  to  the  analysis  of  a  user  guide  tc 
find  unclear  passages,  to  the  analysis  of  industry  standards  for  the 
interchange  of  graphical  ceaputericed  dracings,  to  a  cork 
environeent  prior  tc  the  introduction  of  office  autoaation,  to  the 
design  of  a  database  aanager  and  an  inforaatien  dictionary,  and  to 
the  analysis  and  iaproveeent  of  developaent  aethodologies  including 
Itself. 

S.5  ih{  Uit:  if  Ctiitlmi 

When  coaputers  cere  first  introduced,  the  first  prograaaers  cere 
user  Ciperts  cho  had  to  learn  the  language  of  the  coaputer.  Later, 
Chen  coaputers  becaee  aore  coaplex,  specialists  cere  trained  in  the 
intricacies  of  coaputers.  These  specialists  knee  a  let  about  the 
aachine  but  very  little  about  the  business  and  inforaation  needed  to 
support  it  in  user  areas.  Horse,  they  built  coaputer  seftcare  upon  a 
cental  aodel  of  a  aachine  (disks,  tapes,  records,  keys,  foraats, 
pointers,  pages,  sectors,  etc.)  foreign  to  the  user  and  hence  a 
barrier  to  developaent. 

Today  cith  Inforaation  Analysis  »s  are  seeing  a  change  in  hoc 
systeas  are  developed.  The  user  expert  is  noc  taking  charge  of 
analysing  his  ecn  problea  and  giving  his  specifications  as  require- 
aents  to  the  data  processing  shop.  He  is  no  longer  accepting  a 
passive  role  as  the  victia  of  auteaation;  today  he  is  controlling 
it.  As  a  consequence,  the  nature  of  the  softcare  developaent  process 
is  changing.  In  this  process  the  professional  inforaation  analyst 
acts  as  an  educator,  reviecer,  guide,  and  friend. 
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FIGURE  I.  Ilf  ORMTION  ANALYSIS  ICTH0D0L06Y 


E  RE=R££SNTS  A  SET  OF  LEXICAL 
(UTTER ABLE)  OBJECTS. 


BRIDGE  WHICH  RELATES  A  NONLEXICAL  OBJECT 
TO  A  LEXICAL  OBJECT  THROUGH  ROLES  R*.  AND  R2. 


IDEA  WHICH  RELATES  TWO  NONLEXICAL  OBJECTS 
THROUGH  ROLES  R1  AND  R2. 


THE  OBJECT  "A"  OCCURS  ELSEWHERE 
ON  THIS  OR  ANOTHER  I A  DIAGRAM. 


C 


6,  C  AND  D  ARE  SUBSETS  OF  A.  A  MEMBER 
OF  A  CAN  BE  A  MEMBER  OF  B,  C  OR  D  (OR 
ANY  COMBINATION  OF  B,  C  AND  D) . 
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AUTHOR'S  NOTES 

This  issue  of  the  Data  Specification  LanguagB  replaces  the 
draft  dated  01/27/86.  The  changes  are  mainly  additions  to  the 
text  which  explains  how  the  language  is  used.  Concentrating  on 
Part  III,  here  are  some  items  that  might  be  of  soma  interest: 

III-3.3  defines  lexical  substitution  which  is  patterned  after 
the  'C  Language  implementation. 

ZZI-4  gives  some  detail  about  the  schema  block. 

ZZI-5  gives  some  examples  of  entities.  The  association  entity 
has  been  removed,  but  the  capability  is  implemented  differently. 

ZZZ-8  expands  on  the  idea  of  semantic  types.  This  is  new  for 
this  issue. 

ZZZ-9  talks  to  static  constraints.  This  also  is  new  for  this 
issue. 

There  is  now  a  table  of  contents  for  each  section,  but  the 
page  numbers  have  not  been  filled  in.  I  am  waiting  for  the 
document  to  become  more  stable  before  doing  this  since  it  is  a 
manual  operation  on  the  equipment  I  have  been  using. 

Some  planned  additions  are:  a  discussion  of  the  differences 
and  similarities  between  DSL  and  Cntity^Relationship  modeling  and 
Binary'Relationship  modeling  (that  should  be  interesting) ;  and 
more  annotated  examples.  The  part  about  mapping  to  different 
physical  Implementations  will  probably  resurface  as  an  appendix 
sooner  or  later  too. 

Comments  on  this  work  may  be  directed  to: 

Douglas  Schenck 

McDonnell  Douglas  Aerospace  Information  Services  Company 

MDAZSC 

P.O.  Box  516 

Dept.  W315 

Building  271D 

St.  Louis,  MO  63166 

(314)  234-5258 
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1.  Introduction 

The  Data  Specification  Language  (DSL)  is  a  declarative 
language  used  to  express  an  information  model.  This  manual 
explains  the  principles  of  information  modeling  and  how  DSL  is 
used  to  create  models  of  information  that  are  useful  in 
understanding  how  an  operation  functions. 

Part  I  explains  the  information  modeling  process;  Part  II  is 
a  formal  definition  of  DSL  in  terms  of  (a  form  of)  BNP;  Part  III 
is  a  guide  to  the  use  of  DSL;  Part  IV  is  a  glossary  of  the  terms 
used  throughout  the  manual. 

The  aim  of  information  modeling  is  to  capture  the  essence  of 
the  information  needed  for  the  operation  of  some  enterprise.  Its 
aim  is  not  to  model  data,  i.e.,  to  model  the  form  of  information 
as  it  might  be  used  in  an  application  environment.  It  is  impor¬ 
tant,  however,  that  the  information  model  be  able  to  produce  such 
a  data  model.  In  fact,  the  production  of  data  models [1]  is  the 
second  most  important  role  of  the  information  model. 

This  begs  the  question  -  what  is  the  most  important  role  of 
the  information  model?  It  is  simply  this  -  to  express  what  is 
known  about  enterprise  information.  This  expression  is  aimed 
equally  at  human  users  and  computing  machines. 

The  purpose  of  the  information  processing  system  is  to 
encourage  the  use  and  exchange  of  information.  Both  the  provider 
and  the  receiver  of  data  should  be  able  to  understand  it  in 
exactly  the  same  manner,  i.e.,  to  treat  data  as  information.  The 
use  of  an  information  model  is  aimed  at  avoiding  errors  in 
interpreting  the  meaning  of  data. 

Data  and  information,  as  xised  in  this  document,  have  the 
following  meanings: 

—  Data  is  the  representation  of  information  independent  of 
its  meaning,  e.g.,  an  integer  number. 

—  Information  is  the  data  plus  the  meaning  connected  with 
it.  It  is  any  kind  of  knowledge  about  things  or  concepts 
that  is  exchangeable  among  users,  e.g.,  an  integer  number 
is  the  age,  in  years,  of  some  person. 

The  Data  Specification  Language  (DSL)  enables  the  expression 
of  the  information  needs  of  an  enterprise.  Its  purpose  is  to 


) 


t 


[1]  You  will  notice  that  information  model  is  always  treated  as  a 
singular  thing  while  data  model  is  treated  in  a  plural  sense. 
This  is  because  there  should  be  only  one  information  model, 
but  several  data  models  that  implement  the  information  model 
are  possible. 
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capture  the  neanlng  of  data  so  that  the  provider  and  receiver  of 
data  may  interpret  it  without  error.  DSL  is  not  a  database 
design  tool,  although  it  is  possible  to  derive  a  dat2ibase  design 
from  the  information  model  written  in  DSL. 

2.  The  Information  Model 

The  information  model  establishes  the  framework  within  which 
information  may  be  expressed.  Not  all  kinds  of  information; 
only  the  information  that  can  be  represented  by  an  information 
processing  system.  In  general  this  means  data,  with  meaning,  that 
has  a  realized  form  and  predictable  structures  and  relationships. 
It  is  not  possible,  nor  is  it  necessary,  to  represent  all  kinds 
of  information  about  things.  Nhen  modeling  a  person  for  example, 
there  are  all  kinds  of  qualities  that  defy  a  meaningful 
representation [2 ] ;  how  does  one  feel  about  something  or  what  does 
one  believe  about  some  topic.  Fortunately,  Information 
processing  systems  usually  deal  only  with  concrete  facts  such  as 
a  person's  name  or  age,  or  with . simulations  of  abstract  feelings 
(do  you  strongly  agree,  agree,  strongly  disagree,  etc.  with  this 
or  that  statement) . 

The  information  model  is  concerned  with  the  expression  of 
things  (and  concepts)  needed  by  (for  the  operation  of)  the 
enterprise  of  interest.  The  concepts  needed  to  accomplish  that 
expression  are  briefly  described  here  and  will  be  discussed  in 
more  detail  in  s\3bseq[uent  sections. 

An  entity  is  the  abstraction  of  some  artifact  or  concept  of 
interest  and  use  to  the  enterprise. 

An  attribute  is  a  defining  fact  about  an  entity. 

A  class  is  a  collection  of  entities  that  are  (thought  to  be) 
alike  in  some  manner. 

A  rule  is  a  constraint  which  must  be  enforced  by  the  infor¬ 
mation  processing  system,  e.g.,  an  employee  must  belong  to 
exactly  one  department,  or  all  points  must  be  in  the  first 
octant.  Rules  may  vary  somewhat  among  different,  but  similar, 
enterprises.  Most,  but  perhaps  not  all,  businesses  will  be  in 
accord  with  the  first  example.  Few  geometric  modellers  would 
agree  with  the  second  example. 

An  operation  defines  how  an  entity  may  be  used  within  the 
enterprise  and  what  the  result  of  the  operation  may  be.  e.g.,  a 
number  may  be  used  in  an  add  operation  and  the  result  is  a 
number. 


[2]  Artificial  Intellegence  (AI)  and  advancing  computing 
technology  may  someday  alter  this  vie%/point. 
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A  function  Is  an  algor itha  which  yialds  soma  rasult  object. 

A  procedure  is  an  algorithm  which  operates  on  information  to 
produce  some  desired  end  state. 

The  relationship  is  a  mechanism  used  to  connect  two  entities 
in  some  fashion,  e.g.,  a  Line  uses  a  Point  as  one  of  its 
attributes.  That  would  be  a  defining  relationship. 

The  schema m  is  what  we  call  the  the  information  model.  It 
embodies  what  we  (think  we)  know  about  enterprise  information. 

3 .  Data  Models 

There  may  be  a  number  of  data  models  within  an  enterprise 
that  implement  (part  of)  the  information  model.  It  is  simply 
impossible  to  cover  all  of  the  possible  data  models  that  might  be 
employed.  Even  when  talking  about  a  generic  data  model  (e.g., 
relational)  we  cannot  cover  all  of  the  possible  implementation 
variations . 

However,  the  purpose  of  this  section  is  not  to  discuss 
specific  data  models,  but  to  explain  how  data  models  are 
different  from  the  information  model.  Consider  this  parallel:  we 
have  a  problem  for  which  there  are  many  possible  solutions.  Some 
process  of  elimination  will  yield  a  single  solution  that  seems  to 
be  the  best  according  to  some  criteria.  When  separate  groups 
attempt  to  solve  the  same  problem  we  might  expect  to  find  that 
each  group  produces  a  different  solution.  Very  possibly  each 
group  would  evaluate  the  alternatives  based  on  differing 
criteria. 

The  same  thing  happens  with  the  translation  from  the  infor¬ 
mation  model [4]  to  a  data  model.  Group  A  and  Group  B  look  at  the 
information  model  and  come  up  with  a  data  implementation  that 
best  suits  their  needs  and  environment.  The  best  solution  for 
Group  A  may  not  be  the  best  for  Group  B.  This  does  not  become  a 
problem  until  Group  A  wants  to  share  information  with  Group  B. 

Now  we  need  the  information  model  to  stand  between  the 
separate  implementations  to  interpret  the. meaning  of  data  found 
at  either  side  of  the  exchange.  This  worJcs  best  when  the  infor¬ 
mation  model  is  formal  rather  than  ad  hoc. 


[3]  Not  to  be  confused  with  the  term  conceptual  schema  as  used  by 
the  ANSZ/X3/SPARC  DBSG. 


[4]  We  assume  that  all  are  looking  at  exactly  the  same  infor¬ 
mation  model  and  all  understand  it  exactly  the  same  way. 
When  the  basic  understanding  is  different,  effective 
commxinication  is  impossible. 
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So,  the  data  models  are  concerned  with  application  needs  and 
the  implementation  environment.  The  information  model  must  not  be 
concerned  with  these  issues.  The  information  model  must  express 
concepts  in  a  common  language.  The  data  model  does  not  have  to  do 
this  (but  it  doesn't  hurt  if  it  does). 

4.  Elements  of  the  Information  Model 

A  brief  description  of  the  elements  of  the  information  model 
was  given  earlier.  This  section  explains  them  in  complete  detail. 

4.1  Entity 

An  entity  is  the  abstraction  of  some  artifact  or  concept  of 
interest  and  use  to  the  enterprise.  An  entity  must  posess  these 
qualities: 

—  it  must  express  an  entire  concept 

—  it  must  exist  Independently 

This  means  that  an  entity  must  not  express  a  partial  concept. 
By  way  of  contrast,  data  models  often  express  partial  concepts  in 
physical  structures.  To  exist  independently  means  that  em  entity 
must  not  depend  on  any  other  entity  for  its  existence [5 ] .  Again, 
data  models  often  rely  on  dependent  relationships,  especially 
where  partial  concepts  are  required.  An  example  %(ill  help  to 
illustrate  these  ideas. 

We  wish  to  define  a  FairCurve,  which  is  a  smooth  curve  that 
passes  through  two  or  more  points.  The  behavio\ar  of  the  curve  at 
each  point  is  defined  by  attributes  telling  whether  or  not  slope 
and  curvature  continuity  is  required.  The  very  first  and  last 
points  have  no  such  attributes.  Furthermore,  there  is  an  integer 
niuiber  attribute  of  the  FairCurve  that  somehow  determines  the 
method  of  Interpolation  between  points. 

One  way  of  building  a  data  model  is  with  the  following 
relational  tables  (there  are  other  ways  of  doing  this) : 


[5]  There  is  the  possibility  that  a  particular  entity  nay  be 
treated  as  "dependent  with  respect  to"  another  entity.  See 
dependent  in  4.8. 
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FAIRCURVE 


ZD 

1 

isa 

ZNTERP 

1 

FIRST 

1 

LAST  1 

FCOOOl 

1 

3 

1 

PT1234 

1 

PT3456  1 

FC0002 

etc. 

1 

4 

1 

PT0133 

1 

PT5600  1 

PAIRCURVE-POINT 


ID 

SEQ 

•> 

1 

PTREF 

1 

G1 

1 

62 

FCOOOl 

003 

tmM 

1 

PT7164 

1 

TRUE 

7 

FALSE 

FC0002 

001 

1 

PT4617 

1 

FALSE 

1 

FALSE 

FC0002 

003 

1 

PT4614 

1 

TRUE 

1 

FALSE 

FC0002 

002 

1 

PT7117 

1 

FALSE 

1 

FALSE 

FCOOOl 

002 

1 

PT43I4 

1 

TRUE 

1 

TRUE 

FCOOOl 

001 

1 

PT4143 

1 

FALSE 

1 

FALSE 

FCOOOl 

004 

1 

PT4341 

1 

FALSE 

1 

FALSE 

FC0002 

004 

1 

PT4334 

1 

TRUE 

1 

FALSE 

FC0002 

006 

I 

PT4146 

1 

TRUE 

1 

TRUE 

FC0002 

etc. 

005 

1 

PT4943 

! 

FALSE 

1 

FALSE 

[6] 


First,  it  is  clsar  that  ths  rscords  in  FairCurvsPoint  ars 
dapandant  on  tha  FairCurva  tabla.  i.a.,  if  a  racord  is  raaovad 
from  FairCurva,  than  all  corrasponding  racords  in  FairCurvaPoint 
Bust  ba  raoovad  also.  This  is  a  elua  that  FairCurvaPoint  is 
raally  an  attributa  of  FairCurva.  But  Bora  on  this  latar. 


Zt  is  not  so  claar  vhathar  or  not  a  racord  in  FairCurvaPoint 
can  ba  dalatad  without  affacting  tha  dafinition  of  a  givan 
FairCurva. 


Sacond,  does  FairCurvaPoint  axprass  a  coBplata  idaa?  In 
othar  words,  could  wa  axplain  what  this  ralation  Bsans  without 
calling  up  tha  contaxt  in  idiich  it  is  usad.  Tha  answar  to  this  is 
an  iinqualifiad  Bayba,  but  tha  claiB  hara  is  that  FairCurvaPoint 
cannot  ba  axplainad  without  bringing  FairCurva  into  tha 
discussion  also. 


Ha  can  conclude  froB  this  that  FairCurvaPoint  is  not  an 
entity,  at  least  in  tha  contaxt  of  tha  inforaation  BOdel.  Neither 
is  FairCurva,  since  by  itself  it  is  not  coaplata.  They  Bay  ba 
called  entities  in  tha  jargon  of  tha  particular  data  Bodal  that 


[6]  Notice  that  tha  conbination  of  ZD  and  SEQ  Bust  ba  unique.  SEQ 
gives  tha  ordering  of  points  interior  to  tha  FairCurva. 
Moreover,  in  relational  tables  there  is  no  guarantee  that 
"hay"  values  will  ba  in  any  Baaningful  order.  They  are  shown 
in  randoB  order  to  aaphasiza  this  consideration. 
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is  being  enployed.  X  solution  to  this  problem,  in  information 
modeling  terms,  will  be  given  later. 

4.2  Attribute 

An  attribute  is  a  particular  fact  about  an  entity,  such  as 
is  a  fact  about  Point.  Each  entity  will  have  a  set  of  attributes 
that  make  it  unique  from  all  other  entities.  The  name  of  the 
entity  is  shorthand  for  the  set  of  facts  needed  to  define  it. 

Attributes  may  be  classified  according  to  the  purpose  they 
play  in  the  description  of  an  entity.  The  terms  used  are:  Role 
and  KoRole.  A  purely  conceptual  schema  will  employ  only  Role 
attributes  in  the  description  of  entities.  KoRole  attributes  will 
be  used  as  the  schema. migrates  toward  a  physical  implementation. 

A  Role  attribute  is  essential  for  the  description  of  an 
entity.  If  one  or  more  of  the  Role  attributes  were  eliminated 
from  the  description,  the  meaning  of  the  entity  would  be  lost. 

A  KoRole  attribute,  on  the  other  hand,  is  not  essential  for 
the  understanding  of  the  entity  in  question.  A  KoRole  attribute 
is  (or  may  be)  necessary  for  the  function  of  an  operational 
system. 

One  common  example  of  a  KoRole  attribute  is  the  key  attribute 
which  is  used  to  gain  access  to  a  specific  entity.  These  key 
attributes  are,  more  often  than  not,  manufactured.  The  data 
representation  of  the  key  attribute  is  likely  to  be  different  for 
different  implementations,  e.g.,  a  relational  database  would 
probably  use  a  character  string  for  key  values  while  a  network 
database  would  probably  use  memory  addresses  or  record  pointers 
for  that  purpose. 

In  either  event  the  KoRole  attributes  may  be  ignored  for  the 
purpose  of  understanding  an  entity;  only  the  Role  attributes  are 
essential  for  that  purpose. 

An  attribute  may  be  viewed  as  having  three  components:  the 
name  of  the  attribute;  its  semantic  type;  and  any  constraints 
that  might  be  enforced  on  particular  values  for  its  semantic 
type.  Constraints  may  or  may  not  be  present,  and  if  not  the 
semantic  type  is  unconstrained. 

The  name  of  an  attribute  is  ]cnown  only  to  the  entity  in  which 
it  is  defined,  i.e.,  if  two  entities  have  the  same  attribute 
(name)  there  is  no  inference  that  the  two  attributes  mean  the 
same  thing. 

The  semantic  type  defines  what  the  attribute  is.  It  does  not 
define  how  the  attribute  is  to  be  represented  in  a  specific 
environment.  One  should  not  ass\ae  that  the  semantic  type  Integer 
will  be  realized  as  a  binary  twos  complement  number.  It  could 
also  be  encoded  as  a  packed  or  unpacked  decimal,  or  as  a 
character  string  (of  digits) . 
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Ev«n  though  a  sanantic  typa  and  a  data  typa  ara  usad  In 
dlffarant  rolas,  it  la  difficult  to  saparata  thasa  concapts  in 
practica. 

Tha  saaantic  typas  built  into  DSL  ara  listad  balov.  Part  ZZI 
axplains  how  tha  saaantic  typas  ara  usad. 

SIMPLE 

Kuabar 
—  Intagar 
—  Raal 
—  Float 
—  Pixad 
—  String 
—  Logical 

—  Rafar 

GROUPIMG 
—  Array 
—  List 
—  Sat 

EXISNSJOKAL 
—  Dafinad 

COMPLEX 

—  Enuaaration 
—  Structura 

Kota  that  tha  coaolex  saaantic  typas  (anxmaration  and 
structure)  aay  not  ba  usad  directly  as  saaantic  types.  They  aust 
first  ba  given  a  saaantic  typa  naaa  by  tha  use  of  tha  dafinad 
saaantic  typa. 

4.3  Class 

A  class  is  a  collection  of  things  that  ara  (thought  to  ba) 
alike  in  soaa  Banner.  Unlike  entity,  which  has  soaa  kind  of 
iaplaaantation,  tha  class  is  strictly  abstract.  Thera  ara  no 
instances  of  a  class  in  a  database  anvironaant. 


A  class  aay  contain  either  classes  or  entities  as  aaabars. 
Whan  a  class  is  a  aaabar  of  a  class  it  is  called  a  sxib-class. 
Sub-classes  can  ba  usad  to  define  a  hiararchial  structura  such 
as: 
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Gaoffltttry 
Point 
Curvo 
elrcl* 
lino 
•11 ipse 
•tc. 

Surface 

plane 

cylinder 

cone 

•tc. 

A  nember  of  a  class  can  also  be  a  neaber  of  another  class. 
This  allows  an  entity  to  be  organized  in  different  ways  for 
different  purposes,  e.g., 

Aninal 

wolf 

dog 

cat 

Canine 

wolf 

dog 

fox 

Pet 

dog 

cat 

Oog  is  in  the  classes  aniaal,  canine,  and  pet.  Wolf  is  a 
canine  and  an  aniaal,  but  not  a  pet  (well,  lets  hope  not). 

The  purpose  of  a  class  in  a  conceptual  scheaa  is  to  organize 
and  siaplify.  We  could  define  a  class  called  Geoaetry  with  its 
aembers  being  the  entities  that  are  used  to  represent  position 
and  shape.  Then,  whenever  we  need  soaething  that  represents 
position  and  shape  we  would  refer  to  Geoaetry  instead. 

4.4  Rule 

A  rule  is  an  expression  of  a  constraint  that  is  to  be 
enforced  in  soae  aanner  when  an  entity  instance  is  created  or 
Bodified,  or  possibly,  when  it  is  deleted.  A  rule  sight  be 
enforced  by  a  DBMS,  application  code,  aanual  procedure,  or  by 
other  Beans.  The  expression  of  a  rule  in  the  inforaation  aodel 
does  not  aean  that  the  responsibility  of  enforceaent  falls  on  the 
DBMS. 

Rules  can  be  siaple  or  coaplex.  A  siaple  rule  sight  state 
that  an  attribute  can  only  have  the  values  zero  through  ten.  If 
ve  look  at  the  FairCurve  exaaple  given  earlier  ve  can  observe  a 
Bore  coaplex  constraint;  one  involving  two  attributes.  The  table 
containing  G1  and  G2  has  either  True  or  False  values.  However, 
when  the  value  of  G1  is  False  then  the  value  of  G2  aust  also  be 
False. 
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More  examples  of  rules  can  be  found  in  the  User's  Guide, 

Fart  III  of  this  manual. 

4.5  Operation 

Each  type  of  data  vill  have  some  (possibly  open  ended)  set  of 
operations  that  may  be  performed  on  it.  Each  operation  vill 
yield  some  well  defined  result;  e.g. ,  Curves  may  be  intersected 
yielding  a  point,  dates  may  be  subtracted  yielding  an  age, 
vectors  may  be  crossed  yielding  a  vector,  numbers  may  be  added 
yielding  a  number,  and  so  on.  Presumably,  if  no  operations  are 
defined  for  a  given  type,  there  is  no  need  for  that  type. 

A  significant  part  of  the  discovery  process  should  be 
concerned  with  the  identification  of  the  operation  set  that 
Applies  to  the  data.  Without  that  information  the  infoxrmation 
model  is  incomplete. 

It  is  interesting  to  note  that  in  mathematics,  operations  on 
numbers,  sets,  vectors,  etc.  are  rigorously  defined  and  are  in 
place  as  part  of  the  discipline.  This  account  in  part  for  the 
ability  of  mathematicians  to  communicate  veil  in  uneunbiguous 
terms  vith  one  another.  Mo  less  should  be  expected  from  other 
"disciplines". 

4.6  Function 

A  function  is  a  procedure  that  yields  some  object  as  a 
result.  That  object  may  be  simple  (e.g.,  a  number)  or  complex 
(e.g.,  a  point  entity).  A  function  can  be  compared  to  an 
operation.  The  difference  lies  in  the  vay  it  is  invoked  and  in 
the  manner  in  vhich  inputs  are  presented. 

e.g.,  an  operation  is  stated: 

object  opera tion'-symbol  object  5*6 


where  a  function  is  invoked  by: 

function-name (parameter-list)  add (5, 6) 

In  this  case  the  result  is  exactly  the  same  (the  number  11) . 
The  decision  that  selects  either  a  function  or  an  operation  to 
produce  some  result  is  based  partly  on  convention  and  aesthetics. 

4.7  Procedure 

A  procedure  is  a  collection  of  expressions  that  produces  a 
desired  end  state.  Rules,  operations,  and  functions  are  forms  of 
procedures.  Procedures  may  have  parameters  that  provide  the 
variable  data  on  vhich  operations  are  performed. 
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4.8  Relationship 

A  relationship  relates  two  entitles  in  a  particular  manner.  A 
relationship  can  be  viewed  as  a  special  Jcind  of  entity  with  the 
following  attributes: 

CARDINALITY  defines  the  ratio  of  things  that  are  being 
related  to  one  another  and  Is  specified  by  the  Array,  List,  or 
Set  semantic  types,  or  the  absence  of  any  one  of  these. 

Cardinality  applies  to  relationships  through  the  Refer 
semantic  type  and  to  the  other  non-relational  semantic  types. 

e.g. , 

entity  a; 
role 

b  :  array (10)  of  real; 
c  :  array(10}  of  refer(d); 
e  :  real; 
f  ;  refer (g) ; 
end; 

for  each  a  there  are  10  b* s ;  for  each  a  there  are  10  c's;  for 
each  A  there  is  one  a»  ^ud  for  each  a  there  is  one  X*  lu  the  case 
of  the  s.  attribute  a  relationship  between  a  Aud  fl  is  established. 
In  the  case  of  the  X  attribute  a  relationship  is  established  to 


For  non-relational  semantic  types  the  following  reverse 
cardinality  holds  (using  a  the  entity  and  t  for  the 
attribute) : 

for  each  a  there  are  n  b’s 
for  each  there  is  one  a* 

For  the  relational  semantic  type  (refer)  the  following 
reverse  relationship  holds: 

for  each  a  there  are  n  b's 

for  each  )2  there  may  be  n  a*g. 

That  is,  because  entities  are  independent,  they  may  be  freely 
referenced  by  any  other  entity.  This  has  the  effect  of  yielding  a 
many-to-many  relationship  whenever  a  refer  semantic  type  is 
employed. 

REQUIREDNESS  states  whether  a  particular  attribute  is 
manditory  or  optional.  Optional  attributes  are  sometimes 
meaningful;  e.g.,  in  the  definition  of  a  Face  the  cutouts  are 
optional.  The  use  of  optional  has  the  effect  of  producing  a 
zero-to-n  relationship. 
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DEPENDENCE  states  whether  or  not  the  referenced  entity  of  the 
relationship  owes  its  existance  to  the  refering  entity.  This  is 
aeaningful  only  when  used  with  the  refer  semantic  type.  When 
DEPENDENT  is  used  it  states  that  the  referenced  entity  exists  (in 
this  context)  only  for  the  purpose  of  defining  the  referring 
entity.  In  effect  it  treats  the  referenced  entity  the  same  as  a 
non-relational  semantic  type. 

PURPOSE  states  whether  an  attribute  provides  a  fact  (a  Role 
purpose)  or  ancilary  data  (a  MoRole  purpose)  about  an  entity.  It 
is  not  common  in  information  models  to  provide  NoRole  attributes. 
They  are  often  used  in  data  models. 

4.9  Schema 

The  schema  embodies  all  of  the  separate  constructs  discussed 
before  as  an  information  model.  This  should  not  be  confused  with 
the  terms  conceptual  schema,  external  schema,  and  internal  schema 
as  used  by  the  ANSI/X3/SPARC  DBSG.  Schema  is  used  simply  as 
shorthand  for  information  model. 

5.  The  n-Schema  Framework 

The  ANSI/X3/SPARC  DBSG<1>  gives  us  a  basic  framework  for  a 
three  schema  architecture  comprised  of  conceptual,  external,  and 
internal  schema.  This  architecture  assumes  that  a  database 
management  system  (of  some  kind)  will  be  employed  by  the 
information  processing  system. 

# 

The  conceptual  schema  comprises  a  central  description  of  the 
data  that  may  be  in  a  database.  This  conceptual  schema  may  be 
viewed  in  a  number  of  different  ways  by  users  of  the  data.  These 
views  are  called  the  external  schema.  The  view  of  the  data  as  it 
is  stored  in  a  file  is  called  an  internal  schema. 

This  architecture  conveniently  permits  different  viewpoints 
to  be  expressed  without  interfering  with  the  re<^irements  of 
others  and  works  well  in  a  homogeneous  information  processing 
system  environment. 

We  can  diagreua  this  architecture  as;  ' 

[CONCEPTUAL] 

I 

— + 

I  I 

<p>  <p> 

[EXTERNAL]  [INTERNAL] 

(  <p>  denotes  a  "to-many"  relationship  ) 
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A  fourth  schema  (the  information  model)  can  be  introduced 
into  this  framework  to  account  for  a  heterogeneous  information 
processing  system  environment. 

[INFORMATION  MODEL] 

I 

<P> 

[CONCEPTUAL] 

1  i 

<p>  <p> 

[EXTERNAL]  (INTERNAL] 

That  is,  there  may  be  many  conceptual  schema,  each  one 
expressed  in  the  terms  of  the  particular  database  environment. 
Each  of  these  conceptual  schema  are  derived  from  the  information 
model  of  which  there  is  only  one. 

6.  The  Discovery  Process 

The  information  model  acts  as  a  bridge  between  the  discovery 
of  data  and  the  eventual  implementation  of  it.  The  discovery 
phase  consists  of  the  identification  of  information  and  how  it  is 
used  within  the  enterprise.  Several  existing  methodologies  might 
be  employed  during  this  discovery  phase.  One  important  aspect  of 
this  discovery  phase  is  the  identification  of  the  operations  that 
may  be  performed  upon  information,  the  results  of  operations,  and 
the  behaviour  of  information  while  the  operations  are  being 
performed. 

The  implementation  phase  takes  into  account  the  environment, 
which  includes  the  specific  computer,  operating  system,  database 
management  system,  development  language,  performance  needs,  and 
many  other  considerations  and  constraints. 

Mapping  functions  are  used  between  these  three  phases.  The 
mapping  fxinction  between  discovery  and  the  information  model  is 
probably  manual  in  nature.  It  is  possible  to  automate  toe  mapping 
between  toe  information  model  and  toe  implementation  given  that 
toe  information  model  is  sufficiently  complete. 

PHASE 


i 


I— - 


DISCOVERY 


— <KAP>* 


INFO  MODEL 


■<MAP>‘ 


IMPLEMENTATION 
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.* 

I 

.* 
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7.  Requirements  for  the  Information  Model 

The  information  model  must  fulfill  a  number  of  basic  require¬ 
ments.  Zn  addition,  it  is  desireable  that  it  be  able  to  support  a 
number  of  peripheral  activities  related  to  the  process  of 
creating,  maintaining,  and  documenting  the  information  model. 

Basle  Requirements 

Describe  the  artifacts  needed  for  the  operation  of  a  given 
enterprise.  Mainly  this  meains  accounting  for  the  entities, 
their  names,  attributes,  and  semantic  definitions. 

Define  the  operations  that  are  permissible  for  each  entity 
(and  class  where  appropriate) .  This  also  includes  the 
definition  of  any  preconditions  and  assumptions  connected 
with  the  performance  of  an  operation  (e.g.,  the  two 
vectors  in  a  cross  product  must  not  be  parallel) ,  the 
possible  error  conditions  (e.g.,  what  if  two  curves  don't 
intersect),  and  the  result  type  of  those  operations. 

Define  the  way  entities  are  organized  into  classes  which 
may  be  treated  as  a  whole  for  certain  purposes. 

Define  the  constraints  that  must  be  enforced  on  single  or 
complex  values. 

Accomplish  this  in  a  way  that  is  usable  by  both  people  and 
computing  equipment. 

Secondary  Requirements 

Capture  the  information  model  as  an  encoded  computer  model 
(not  just  a  text  file) . 

Produce  from  this  encoded  computer  model  a  variety  of 
presentations  aimed  at  different  people  and  activities. 
Some  examples  of  these  presentations  are:  entity 
relationship  diagrams,  binary  relationship  diagrams, 
natural  language  (English,  German,  French,  etc.) 
narriative  of  the  content  of  the  information  model,  cross 
references,  and  so  on. 

Automatic  production  of  end  user  documentation.  This  has 
been  separated  from  the  paragraph  above  to  emphasize  its 
importance . 

Production  of  reports  to  isolate  differences  between 
versions  of  the  information  model. 

Production  of  secondary  forms  of  the  information  model, 
e.g.,  database  definitions,  procedural  code,  data 
declarations,  exchange  file  formats,  etc. 
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8.  The  Role  of  the  Information  Model 

The  information  model  is  a  central,  \inique,  and  neutral 
expression  of  the  information  needed  by  some  enterprise.  It  is 
Independent  of  the  form  actually  taken  by  an  implementation.  It 
makes  visible  to  both  human  users  and  computers  the  content,' 
structure,  and  most  Importantly,  the  meaning  of  the  data 
described  by  it;  albeit  meaning  probably  has  a  different  flavor 
to  humans  and  computers. 

Since  the  information  model  might  be  Implemented  in  different 
ways  by  different  systems,  a  way  of  coordinating  those 
differences  is  needed.  These  are  differences  of  fora  and  not 
meaning.  The  information  model  provides  this  coordination,  along 
with  mapping  schema,  which  at  this  time  must  be  expressed  in 
procedural  terms . 

For  example,  say  the  information  model  defines  line  as  a 
point  and  a  vector,  but  that  some  foreign  CAD  system  defines  it 
as  two  points.  The  mapping  between  the  different  forms  is 
accomplished  by  a  collection  of  procedures  called  a  translator. 
The  translator  must  convert  the  intent  of  the  forei^  format  to 
the  intent  of  the  information  model.  These  conversions  are 
sometimes  trivial,  but  they  can  be  vexingly  difficult  also.  One 
Important  consideration  while  building  an  information  model  is  to 
make  conversion  (as)  easy  (as  possible) . 

The  roles  of  the  information  model  are  summarized  below: 

1.  To  provide  a  common  basis  for  understanding  the 
characteristics  and  behaviour  of  the  information  for  the 
enterprise  of  interest. 

2.  To  provide  a  basis  for  the  realization  of  the  physical 
form  which  represents  these  information. 

3.  To  provide  a  basis  for  the  mapping  between  different 
physical 

The  enterprise  determines  the  requirements  for  what  is  in  the 
information  model  and  how  it  is  expressed.  Since  STEP  is  an 
exchange  enterprise  the  focus  is  on  the  transfer  of  meaning, 
rather  than  on  computational  efficiency.  The  external  view 
(i.e.,  the  way  a  particular  CAD/ CAM  system  sees  an  entity)  of  the 
same  data  may  be  very  much  different  since  its  priorities  are 
probably  different.  The  external  system  ma^  choose  to  represent 
geometry  by  coefficients  to  agree  with  particular  algorithms  and 
to  improve  computational  efficiency.  Each  external  environment 
will  have  its  own  viewpoint  about  what  is  needed  to  support  its 
operational  requirements. 
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(Basic) 


(Basic) 


(Basic) 


(Basic) 

(Basic) 


(Basic) 

(Basic) 

(Basic) 


(Basic) 

(Basic) 


Alphabetical  Index  te  Rlenents 


II-OO . <ACTIOir-BODy> 

II-OO . <ARITH-OP> 

II-OO  .  <ARRAY-TY?E> 

II-OO  . <ASSIGNMENT-STATEMENT> 

II-OO  . <ATTRIB-ID> 

II-OO  . <ATTRIBUTE-BODY> 

II-OO  . <ATTRIBUTE-DECL-STKT> 

II-OO . <ATTRIB13TE-DECL> 

II-OO . <ATTRIBUTE-HEADER> 

II-OO . <BETWEEN-CLAUSE> 

II-OO  .  <BI-PRECISION-SPEC> 

II-OO  . . <BLOCX-DECL> 

II-OO  . . <BLOCK-MEMBERS> 

II-OO  . <BOUNO-SPEO 

II-OO  .  <CASE-ACTION> 

II-OO  .  <CASE-BLOCK> 

II-OO  .  <CASE-LABEL> 

II-OO  .  <CASE-OTHERWISE> 

II-OO  . <CASE-STATEMENT> 

II-OO  . <CHARACTER> 

II-OO  . <CLASS-BOOy> 

II-OO  . <CLASS-DECL> 

II-OO  . <CLASS-H£ADER> 

II-OO  . <CLASS-ID> 

II-OO . <COKP-OP> 

II-OO  . <COMPLEX-SEMANTIC-TYPE> 

II-OO  . <COMPOOND-STATEMENT> 

II-OO . <COHDITION-SPEO 

II-OO . <CONDITION> 

II-OO  .  <CONSTITUENT-LIST> 

II-OO  . <CONSTITUENT> 

II-OO  .  <DEFINED-TYPE-B0DY> 

II-OO  .  <DEFINED-TYPE-DECL> 

II-OO  . <DEFINED-TYPE-HEADER> 

II-OO  .  <DEFINED-TYPE> 

II-OO . <DIGIT> 

II-OO . <DOliKY-STATEMEllT> 

II-OO  . <EMBEDOED-REKARK> 

II-OO  .  <ENTITY-BODY> 

II-OO . <ENTITY-DECL> 

II-OO . <ENTITY-HEADER> 

II-OO . <ZNTITY-ID> 

II-OO . <EIIUM-ID-LIST> 

II-OO . <EKUM-ID> 

II-OO  .  <EKUMERATION-TYPE> 

II-OO  .  <ESCAPE-STATEK£NT> 

II-OO  .  <EXPR£SSION-EXT> 

II-OO  .  <EXPR£SSIOM> 

II-OO . <FACTOR> 

II-OO . <PIXED-LITERAL> 

II-OO  .  <FIXED-TYPE> 

II-OO . <rLOAT-LITERAL> 

II-OO  .  <rLOAT-TYPE> 


II-l 


Z60/TC184/SC4/WG1: 4.1.1  (DRAFT) 
DATA  8PBCIFZCATI0N  LANGUAGE 


14  KAR  1986 
PART  II  —  SYNTAX 


II-OO .  <FORMAL^PASAMZTER-LIST> 

II-OO  . <FORMAL-PARAMETER> 

II-OO  . <FUNC-BODY> 

II-OO  . <FUNC-DECI> 

II-OO  . <FUNC-HEADER> 

(Basic)  II-OO  .  <FUNC-ID> 

II-OO  .  <FUNCTION-CALL> 

(Basic)  II-OO  .  <ID-CHAR> 

II-OO  .  <IDENTIFIER-LIST> 

(Basic)  II-OO  .  <IDENTIFIER> 

II-OO  . <IF-STATEMENT> 

II-OO . <IN-CLAUSE> 

II-OO  . <INCREMENT-CONTROL> 

II-OO . <INT-LIT-ID> 

(Basic)  II-OO  . <INTEGER-LITERAL> 

II-OO  . <INTEGER-TYPE> 

(Basic)  II-OO  .  <LETTER> 

II-OO  . <LEXICAL-CONSTANT-BODY> 

II-OO  . <LEXICAL-CONSTANT-DECL> 

II-OO  . <LEXICAL-CONSTANT-HEADER> 

II-OO  . <LEXICAL-CONSTANT> 

(Basic)  II-OO  . .  <LEXICAL-ID> 

II-OO  .  <LIKE-CLAOSE> 

II-OO . <LIKE-STRING> 

II-OO  . <LIMIT-SPEO 

II-OO  . <LIMIT> 

II-OO  . <LIST-TYPE> 

II-OO  . <LIT-ID> 

II-OO . <LITERAL-LIST> 

II-OO  . <LITERAL> 

II-OO  .  <LOCAL-BODY> 

II-OO  .  <LOCAL-DECL> 

II-OO  . <LOCAL-HEADER> 

(Basic)  II-OO  .  <LOCAL-ID> 

II-OO  . <LOGI^AL-CLAUSE> 

(Basic)  II-OO  .  <LOGICAL-LITERAL> 

II-OO  . <LOGICAL-OP> 

II-OO . . .  <LOGICAL-TYPE> 

(Basic)  II-OO  .  <LOWER> 

II-OO  . <NEST> 

(Basic)  II-OO  .  <NEWLINE> 

II-OO  . <NULL-CLAUSE> 

II-OO  . <OPER-DECL> 

(Basic)  II-OO . .  <OPER-ID> 

II-OO  .  <OPERATION-BODY> 

II-OO  .  <OPERATION-HEADER> 

II-OO  . <OPERATOR> 

II-OO  . <PARAKETER-LIST> 

II-OO . <PARAKETER> 

II-OO  .  <PRECISIOM-SPEC> 

II-OO  . <PROC-BODY> 

II-OO  . <PROC-CALL-STATEMENT> 

II-OO  . <PROC-DECL> 

II-OO  . <PROC-HZADER> 

(Basic)  II-OO  .  <PR0C-1D> 
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II-OO . <QUALIFIED-SEMANTIC-TYPE> 

(Basic)  ZI-00  .  <QUOTE> 

II-OO  .  <REFER-TYPE> 

(Basic)  II-OO . <REMAR]0 

II-OO . <REPEAT-CONTROL> 

II-OO  .  <REPEAT-STATEMENT> 

(Basic)  II-OO  .  <REPLACE-ID> 

II-OO  .  <RESULT-TYPE> 

II-OO . <RULE-BODY> 

II-OO . <RULE-CALL> 

II-OO . <RULE-OECL> 

II-OO . <RULE-HEADER> 

(Basic)  II-OO  .  <RULE-ID> 

II-OO  .  <SCHEKA-BODY> 

II-OO . <SCHEMA-DECL>  ***  ROOT  CONSTRUCT  *** 

II-OO . <SCHEMA-HEAOER> 

(Basic)  II-OO  .  <SCHEMA-ID> 

II-OO  .  <SCHEMA-INFO-KEYWD> 

II-OO  . <SCHEMA-INFO> 

II-OO  . <SEMANTIC-TYPE> 

(Basic)  II-OO  .  <SIGN> 

II-OO  . <SKIP-STATEMENT> 

(Basic)  II-OO  .  <SPACE> 

(Basic)  II-OO  .  <SPECIAL-CHAR> 

II-OO  . <STATEMZNT> 

(Basic)  II-OO . <STRING-LITERAL> 

II-OO  . <STRING-OP> 

II-OO  .  <STRING-TYPE> 

II-OO  .  <STRUCTURE-TYPE> 

(Basic)  II-OO  .  <TAB> 

(Basic)  II-OO . <TAIL-R£MARK> 

(Basic)  II-OO  .  <TYPE-ID> 

II-OO  . <TYPE-SPEC> 

(Basic)  II-OO  . <UNSIGMED-NXJMBER> 

II-OO  . <UNTIL-CONTROL> 

(Basic)  II-OO  .  <UPPER> 

II-OO  .  <WHER£-CLAUSE> 

II-OO . <NHII£-CONTROL> 

(Basic)  II-OO  .  <WHITE-SPACE> 

II-OO  . <WITH-STATEMENT> 
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1.  Notation 


A  kind  of  BNF  is  used  to  present  the  syntax  of  the  Data 
Specification  Language.  The  notation  conventions  are  given 
below.  These  syntax  definitions  are  given  with  a  niniaum  of 
conaentary.  Part->III  explains  usage. 


1.  A  word  enclosed  in  angle  brackets  is  an  element  of  the 
language.  The  word  inside  the  brackets  is  the  name  of 
the  element. 

e . g . ,  <char acter> 

2.  A  literal  is  displayed  as  italic  characters.  All 
literals  are  written  exactly  as  shown,  except  either 
upper  or  lower  case  letters  nay  be  used. 

3.  The  vertical  bar  is  the  "or"  operator,  which  means  that 
a  choice  is  to  be  made  from  the  elements  separated  by 
it. 

e.g.,  <letter>  |  <digit> 

4.  An  element  enclosed  in  square  brackets  is  optional,  that 
is,  it  may  occur  zero  or  one  times. 

e.g.,  C  <opt ional> ] 

5.  An  element  with  an  ellipsis  suffix  may  be  repeated  many 
times . 

e.g.,  <one-or-more> . . . 
e.g.,  [<zero-or-more>] . . . 

8.  The  symbol  indicates  a  production.  The  element  on 
the  left  is  defined  to  be  the  elements  on  the  right. 

e.g.,  <ldentifler>  <letter>  C<ld-char>] . . . 

9.  A  remark  in  the  syntax  descriptions  is  designated  by  >> 
and  the  text  following  on  the  same  line.  This  is 
similar  to  the  tail  remark  of  the  language. 

10.  Parentheses  are  used  in  the  grammar  as  necessary  to 
avoid  ambiguity. 

11.  The  grammar  rules  are  divided  into  three  sections  and 
are  listed  in  alphabetical  order  within  each  section. 
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<ACTION-BODY> 

C<BLOCK-DECL>] 
C<L0CAL-DECL>3 
< COMPOUND-STATEMENT> 


<ARITH-OP> 

<ADD-OP>  1 
<SUB-OP>  I 
<MULT-OP>  I 
<REAL-DIV-OP>  I 
<EXP-OP>  I 
<INT-DIV-OP>  I 
<MOD-OP> 


<ARRAY-TYPE>  ; 

array  <BOUND-SPEC>  ot  <QUALIFIED-SEMANTIC-TYPE> 


<ASSIGNMENT-STATEMENT>  : 

<IDENTIFIER>  •  <EXPRESSION>  ; 


<ATTRIBUTE-BODY>  : 

<ATTRIBUTE-DECL-STMT>. . . 


<ATTRIBUTZ-DECL-STMT> 

<IDENTIFIER-L1ST>  :  [optional]  [dependant] 
<QUALIFIED-SEMANTIC-TYPE>  [<WH£RE-CLAUSE>]  ; 


<ATTRIBUTE-DECL> 

<ATTRIBUTE-HZADER> 

<ATTRIBUTE-BODY> 


<ATTRIBUTE-HEADER> 
key  I 
role  I 
kmyrolB  \ 
norole 


<BETWEEN-CLAUSE>  : 

<LIT-ID>  Jbetveen  <LIT-ID>  en<i~op  <LIT-ID> 


<BI-PRECISION-SPEC>  : 

(  <INTEGER-LITERAL>  ,  <IirrEGER-LITERAL>  ) 
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<BLOCK-DECL> 

[ <BLOCK-MZMBERS> ] 


<BLOCIC-MEMBERS>  : 

<DEFINED-TypE-DECL>  ( 
<ENTITV-DECL>  1 
<CLASS-DECL>  | 
<FUNC-DECL>  I 
<PROC-DECL>  I 
<RULE-DECL>  | 
<OPER-DECL>  I 
<LEXICAL-CONSTANT-DECL> 


<BOUND-SPEC> 

(  <EXPR£SSION>  [  :  <EXPRESSI0N>  )  ) 


<CASE-ACTION>  ! 

<CASE-LABEL>  .*  <STATEMENT> 


<CASE-BLOCK> 

<CASE-ACTION>. . . 

C  <CASE-OTHERWISE> ] 

mnd  ; 


<CASE-LABEL> 

<LITERAL>  [<,  <LITERAL>  j  .  .  . 


<CASE-OTHERWISE>  : 

oth^Dfise  ;  <STATEMENT> 


<CASE-STATEMENT> 

case  <IDENTIFI£R>  of 
<CASE-BLOCIO 


<CIASS-BODY> 

Of  <CONSTITUENT-LIST>  / 


<CIASS-DECL> 

<CIASS-H£ADER> 

[<CLASS-BODY>] 


<CLASS-HEADER> 

class  <CIASSoID> 
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<COMP-OP> 

<LESS-THAN>  | 
<GREATER-THAN>  1 
<EQUAL>  i 
<LESS-EQUAL>  | 
<GREATER-EQUAL>  I 
<NOT-EQUAL> 


<COMPLEX-SEHANTIC-TYPE>  : 
<STRUCTURE-TYPE>  | 
<ENXJMERATION-TYPE> 


<COMPOUND-STATEMSNT>  ; 
b9gin 

C<STATEMENT>] . . . 
mnd  ; 


<CONOITION-SPEC>  : 

<CONDITION>  C<L0GICAL-0P>  <C0NDITI0N>]  . .  . 


<CONDITION> 

<LOGICAL-CLAUSE>  | 
<BETWEEN-CLAUSE> 
<IN-CLAUSE>  I 
.  <LIKE-CLAUSE>  1 
<NULL-CLAUSE> 


<C0NSTITUENT-LIST>  : 

(  <CONSTITUENT>  <CONSTITUENT>] .  .  .  ) 


<CONSTITUEirr> 
<CLASS-ID>  I 
<ENTITY-ID> 


<DEriNED-TYPE-BODY> 
<DEFINED-TYPE>, . . 


<DEFINED-TYPE-DECL> 

<DEFINED-TYPE-HEADER> 

<DEFINED-TYPE-BODY> 


<DEFINED-TYPE-HEADER> 

type 
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<DEFINZD-TYPE> 

<TYPE-ID>  »  <QDALIFIED-SEMANTIC-TYPE>  C<WHERE -CLAUS E>]  ; 


<DUMMY-STATEMENT>  : 
/ 


<ENTITY-BODY>  : 

<ATTRIBUTE-DECL>. . . 
end  ; 


<ENTITY-DECL> 

<ENTITY-HEADER> 

C<ENTITY-BODy>] 


<ENTITY-HEADER>  : 

entity  <ENTITY-ID>  C<WHERE-CLAUSE>]  ; 


<ENUMERATION-TYPE> 

enumeration  of  <ENUM-ID-LIST> 


<ESCAPE-STATEMENT> 
escape  j 


<EXPRESSION-EXT> 

<OPERATOR>  <FACTOR> 


<EXPRESSION> 

C+  I  -  ]  <FACTOR>  C<EXPRESSION-EXT>]... 


<FACTOR> 

<IDENTIFIER>  | 
<LITERAL>  1 
<FUNCTION-CALL>  1 
<NEST> 

<NOT-OP>  <FACTOR> 


<FIXED-TYPE> 

fixed  i  (  <PRECISION-SPEC>  |  <BI-PRECISION-SPEC>  )  ] 


<FLOAT-TYPE>  : 

float  C<PR£CISI0N-SPEC>3 
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<FORMAL-PARAMETER-LIST>  : 

(  [  <FORMAL-PARAMETER>  [/  <F0P11AL-PARAMETER>] . , .  ]  ) 


<FORMAL-PAPAMETER>  : 
[var  ]  <TYPE-SPEC> 


<FUNC-BODY> 

<ACTION-BODY> 


<FUNC-DECL>  : : ■ 
<FUNC-HEADER> 
<FUNC-BODY> 


<FDNC-HEADER>  : 

/unction  <rUNC-ID>  (  C<FORMAL-PARAMETER-LIST>] 
)  :  <RESULT-TYPE>  / 


<FU1ICTI0N-CALL>  : 

<FUNC-ID>  <PARAMETER-LIST> 


<IDENTIFIER-LIST> 

<IDENTIFIER>  <IDENTIFIER>] . . . 


<IF-STATEMENT> 

i/  <CONDITION-SPEC>  then  <STATEMZHT> 
[else  <STATEMENT>] 
end  ; 


<IN-CLAUSE> 

<LIT-ID>  in-op  <LITERAL-LIST> 


< INCREMENT -CONTROL> 

<LOCAL-ID>  *  <LIT-ID>  to  <LIT-ID>  [2>y  <LIT-ID>] 


<INT-LIT-ID> 

<INTEGER-LITERAL>  I 
<IDENTIFIER> 


<INTECER-TYPE>  : 

integer  C<PRECISION-SPEC>] 
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<LEXICAL-CONSTANT-BODY>  : 
<LEXICAL-CONSTANT>. . . 


<LEXICAL-C0NSTA2JT-DECL>  : 

<LEXICAL-CONSTANT-HEADER> 

<LEXICAL-CONSTAirr-BODY> 


<LEXICAL-CONSTANT-HZAOER> 

define 


<LZXICAL-CONSTANT>  : 

<LEXICAL-ID>  *  <LEXICAL-CONSTAirr>  / 

»  Vote  that  tha  semicolon  character  may  not  be  part  of  « 
»  the  lexical-constant  as  it  is  used  as  a  terminator  « 


<LIKE-CIAUSE>  I!- 

<LIT-ID>  like^op  <LIKE-STRING> 


<LIKE-STRING>  : 

<STRING-LITERAL>  1 
<IDENTIFIER> 


<LIMIT-SPEC> 

(  <LIMIT>  ) 


<EXP^SSION>  to  <EXPRZSSION>  |  ? 

»  ?  is  used  to  denote  an  indefinite  upper  bound  « 


<I<IST*TYPE^  • 

list  <LIMiT-SPEC>  of  <QUALIPIED-SEMANTIC-TYPE> 


<LIT-ID> 

<LITERAL>  I 
<IDENTIFIER> 


<LITERAL-LIST> 

(  <LITERAL>  i,  <LITERAL>]...  ; 
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<LITERAL> 

<FLOAT-LITERAL>  | 
<FIXED-LITERAL>  | 
<INTEGER-LITERAL>  | 
<STRING-LITERAL>  ) 
<LOGICAL-LITERAL> 


<LOCAL-BODY> 

<ATTRIBUTE-DECL-STMT> ...  / 


<LOCAL-DECL>  ; 

<LOCAL-HEADER> 

<LOCAL-BOOy> 


<LOCAL-HEADER> 

local 


<LOGICAL-CLAUSE>  : 

<EX?RESSION>  [<COMP-OP>  <EXPRESSI0N>3 


<LOGICAL-OP> 
<AND-OP>  1 
<OR-OP> 


<LOGICAL-TypE> 

logical 


<NEST> 

(  <EXPRESSION>  ) 


<NULL-CLAUSE>  :  :«■ 

<IDENTIFIER>  is  null 


<OPER-DECL>  :  :*■ 

<OPERATION-HEADER> 
[ <OPERATION-BODY> ] 


<OPERATION-BODY>  : 
<ACTION-BODY> 


MAR  1986 
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<OPERATION-HEADER>  : 

operation  <IDENTI?IER> 

(  C<IDENTIFIER>  ,]  <STRING-LITERAL>  <IDENTiriER>  ) 
:  <QUALIFIED-SEMANTIC-TYPE>  / 


<OPERATOR> 

<ARITH-OP>  I 
<STPING-OP>  1 
<LOGICAL-OP>  1 
<COMP-OP> 


<PARAMZTER-LIST>  : 

(  C  <PARAMETER>  i,  <PARAMETER>] . . .  ]  ) 


<PARAMETER>  ! ;• 
<FACTOR> 


<PRZCISION-SPEC> 

(  <INTEGER-LITERAL>  ) 


<PROC-BODY>  : 

<ACTION-BODY> 


<PROC-CALL-STATEMENT> 

<PR0C-1D>  <PARAMETER-LIST>  / 


<PROC-DECL> 

<PROC-HEADER> 

<PROC-BODY> 


<PROC“HEADER>  I  :*■ 

procedure  <PROC-ID>  (  [<FORMAL-PARAMETER-LIST>]  )  / 


<QUALIFIED-SEMAWTIC-TYPE>  : 
<FIXED-TYPE>  I 
<ARRAY-TYPE>  | 
<LIST-TYPE>  I 
<REFER-TYPE>  | 
<STRING-TYPE>  | 
<INTEGER-TYPE>  | 
<FLOAT-TYPE>  | 
<L0G1CAL-TYPE>  | 
<NXmBER-TYPE>  | 
<TYPE-ID> 
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<REFER-TYPE>  ; 

refer  C<CONSTITUENT-LIST>] 


<REPEAT-CONTROL> 

C<INCREMENT-CONTROL>]  [<WHILE-C0NTRL>3  C<UNTIL-CONTROL>] 


<REPEAT-STATEMENT>  ; 

repeat  <REPEAT-CONTROL>  / 
[<STATEMENT>] . . . 
end  ; 


<RESULT-TYPE> 

<QUALIFIED-SEMAKTIC-TYPE>  I 
<ENT1TY-1D> 


<RULE-BODY> 

<ACTION-BODY> 


<RULE-CALL> 

<RULE-ID>  <PARAMETER-LIST> 


<RULE-DECL>  !:- 
<RULE-HEADER> 
<RULE-BODY> 


<RULE-HEADER>  : 

rule  <RULE-ID>  (  C<F0RMAL-PARAMETER-LIST>3  ;  ; 


<SCHZMA-BODY> 

C<SCHEMA-INFO>] . .  . 
<BLOCK-DECL> 
end  ; 


<SCHEMA-DECL>  : 

<SCHEMA-HEADER> 

[<SCHZMA-BODY>] 


<SCHEMA-HZADER> 

schema  <SCHEKA>ID> 
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<SCH131A-INF0-KEYWD> 
title  I 
author  | 
version 


<SCHEMA-INro> 

<SCHZMA-INFO-KEYWD>  <STRING-LITERAL>  / 


<SEMANTIC-TYPE>  : 

<COMPLEX-SEMANTIC-TYPE>  | 
<QUALIFIEO-SEMANTIC-TYPE> 


<SKIP-STATEMENT>  : 
skip  i 


<STATEKENT>  : 

<RZPEAT-STATEMENT>  | 
<CASE-STATEMENT>  | 
<IF-STATEMENT>  1 
<COMPOUND-STATEMENT>  1 
<WITH-STATEMENT>  | 
<PROC-CALL-STATEMENT>  | 
<ASSIGNMENT-STATEMENT>  | 
<ESCAPE-STATEMENT>  | 
<SKIP-STATEMENT>  i 
<DUMMY-STATEMENT> 


<STRING-OP> 

<CONCAT-OP> 


<STRING-TYPE>  : 

String  C<PRECISI0N-SPEC>]  [varyinsr  ] 


<STRUCTURZ-TYPE> 
structure  ; 

<ATTRIBUTE-DECL-STMT>...  / 
mnd 


<TYPE-SPEC> 

<IDENTIFIER-LIST>  ;  <QUALIFIED-SEI1ANTIC-TYPE> 


<U)mL-CONTROL> 

until  <CONDITIOM-SPEC> 
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<WHERE-CLAUSE>  ::«• 
fcrher*  <RULE-CALL> 


<RULE-CALL>]  . . . 


<WHILE-CONTROL> 

while  <CONDITION-SPEC> 


<WITH-STATEMENT>  : 

with  <IDENTIFIER> 
<COMPOUND-STATEMElfr> 
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<ATTRIB-ID> 

<IDENTIFIER> 


BASIC  CONSTRUCTS 


<CHARACTZR> 
<LETTER>  I 
<DIGIT>  I 
<SPECIAL-CHAR> 


<CIASS-ID> 

<IDENTIFIER> 


<EMBEDDED-REMARK>  ; 

(*  C<CHARACTER>]...  *J 


<ENTITY-ID> 

<IDENTIFIER> 


<ENUM-ID-LIST> 

(  <ENUM-ID>  [,  <ENUM-ID>]...  ) 


<ENUM-1D> 

<IDENTIFIER> 


<FIXZD-LITERAL>  : 

<INTEGER-LITERAL>  .  [<INTEGER-LITERAL>3 


<FLOAT»LITERAL>  : 

<FIXZD-LITERAL>  •[+!-]  <I1ITEGER-LITERAL> 


<rONC-lD> 

<IDENTIFIER> 


<ID-CHAR> 

<LETTER>  I 
<D1GIT>  1 

»  The  Underscore  Character  « 


<IDENTIFIER>  : 

<LETTER>  [<ID“CHAR>] . . . 
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<INTEGER-LITERAL> 
<DIGIT>. . . 


<LETTER>  : :■ 
<UPPER>  I 
<LOWER> 


<LEXICAL-ID> 

#  <IDENTIFIER> 


<LOCAL-ID> 

<IDENTIFIER> 


<LOGICAL-LITERAL>  : 
true  I 
falsa 


<OPER-ID> 

<IDENTIFIER> 


<PR0C-ID> 

<IDENTIFIER> 


<R£KARK> 

<EMBEOOEO-R£KARR>  | 
<TAIL-RZMARK> 


<RULE-ID> 

<IDENTIFIER> 


<SCHEMA-ID> 

<IDENTIFIER> 


<SIGN> 

*  I  - 


<STRING-LITERAL> 

<QUOTE>  <CHARACTER>. . .  <QUOTE> 

»  If  a  quote  is  to  be  part  of  a  string,  then  use  two  << 
»  consecutive  quotes,  e.g.,  *John''s  booh  « 
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<TAIL-REMARK> 

—  [<CHARACTER>3  <Ni:WLINE> 

»  Two  consAcutlvo  hyphens  start  a  tall  remark  « 


<TYPE-ID> 

<IDENTIFIER> 


<UNSIGNED-NUMBER>  : 

<INTEGER-LITERAL>  | 
<FIXED-LITERAL>  | 
<FLOAT-LITERAL> 


<WHITE-SPACE>  tim 
<SPACE>  I 
<TAB>  1 
<NEWLINE>  I 
<R£MARR> 
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BA8IC 

ELEMSNT8 

<DIGIT> 

e  • 
e  • 

m 

0  1 

1 

1 

2 

1  3 

1 

4 

1 

5 

1 

6 

1 

7 

1 

8  1  9 

<LOWER> 

e  e 
•  e 

a 

a  1 

b 

1 

c 

1  d 

1 

e 

1 

f 

1 

g 

1 

h 

1 

1  1 

j  1 

k 

1 

1 

1  a 

1 

n 

1 

o 

1 

p 

1 

g 

1 

r  1 

•  1 

t 

1 

u 

1  V 

1 

V 

1 

X 

1 

y 

i 

z 

<Ni:wLlNZ> 

»  laplementation  Dependen't  « 

<QUOTE>  : : ■ 

•  »  Apostroph*  « 


<SPACZ> 

»  Blank  Space  Character  « 


<SPECIAL-CHAR> 

»  Any  Character  That  Ze  Hot  A  <LETTER>  Or  A  <DIGIT>  « 


<TAB> 

»  laplenentation  Dependent  « 


<UPPER> 

A|B|C|D|E|F|G| 

J|K|L|M|N|0|P| 

S|T|U|V|W|X|Y| 


H  I  I  I 
Q  I  R  I 
Z 
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OPERATOR  EQUZVXLEMCB  TABLE 


I  <RZAL-OIV-OP>  I  / 


<EXP-OP> 


<EQnAL> 
<RANGE>  i 

I 

i  <LESS-EQUAL> 

I - , 

I  <GREATER-EQUAL>  | 

<NOT-EQUAL> 

<AND-OP> 

<NOT-OP>  i 

- 1 

<OR-OP>  I 


i  range  j 


I  not 

ft 


I  I 

I  or  I 
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TABLE  OF  KEYWORDS 


A 

ARRAY 

ASSOC 

AUTHOR 

B 

BEGIN 

BY 

BETWEEN 

BOUND 

C 

CASE 

CLASS 

D 

DEFINE 

E 

ELSE 

END 

ENTITY 

ENUMERATION 

ESCAPE 

F 

FIXED 

FLOAT 

FUNCTION 

I 

IF 

INPUT 

INTEGER 

IS 

K 

KEY 

XEYROLE 

L 

LIST 

LOCAL 

LOGICAL 

N 

NOROLE 

NUMBER 

0 

OF 

OPERATION 

OTHERWISE 

P 

PROCEDURE 

R 

RANGE 

REFER 

REPEAT 

ROLE 

RULE 

S 

SCHEMA 

STRUCTURE 

SKIP 

STRING 

T 

THEN 

TYPE 

TITLE 

TO 

U 

UNARY 

UNTIL 

UPDATE 

V 

VALUES 

VERSION 

VAR 

VARYING 

w 

WHERE 

WHILE 

WITH 

11-21 


X80/TC184/8C4/W61:4.1.1  (DRAFT) 
DATA  8PECI7ICATZ0N  LANGUAGE 


PART  ZZI 


14  MAR  1986 
USER* 8  GUIDE 


Table  of  Contents 


1.  SYNTAX 

2.  BASIC  LANGUAGE  ELEMENTS 

2.1  Character  Set 
Letters 
Underscore 
Digits 

Special  Characters 
Coapovmd  Symbols 

2.2  Reserved  Words 

2.2.1  Keyvords 

2.2.2  Standard  Identifiers 

2.2.3  Compound  Symbols 

2.3  Program  Lines 

3.  USER  DEFINED  LANGUAGE  ELEMENTS 

3.1  Identifiers 

3.2  Literals 

3.2.1  Integer  Literal 

3.2.2  Fixed  Literal 

3.2.3  Float  Literal 

3.2.4  String  Literal 

3.2.5  Logical  Literal 

3.3  Lexical  Sxibstitution 

3.4  Comments 

4.  SCHEMA 

5.  ENTITY 

6.  CLASS 

7 .  ALGORITHMS 

7.1  Procedure 

7.2  Function 

7.3  Rule 

7.4  Operation 

7.5  Expressions 

7.6  Built-in  Functions 

8.  SEMANTIC  TYPES 

8.1  Simple  Types 

8.2  Grouping  Types 

9.  STATIC  CONSTRAINTS 

9.1  Range 

9.2  Bound 

9.3  Values 

9.4  Summary 


III-l 


Z80/TC184/8C4/V61:4.1.I  (DRAFT) 
DATA  8PECIPICATZ0N  LANGUAGE 


14  MAR  1986 
PART  ZZZ  —  U8ER*8  GUIDE 


1.  syntax 

The  syntax  of  DSL  is  defined  formally  in  Part  IZ  of  this 
docxunent.  This  part  is  aimed  at  explaining  how  the  constructs  are 
put  together  to  create  a  schema  definition. 

DSL  can  be  characterized  as  block  structured  and  free  form. 
The  free  form  characteristic  means  that  one  statement  may  span 
several  physical  lines,  or  that  several  statements  may  be  written 
on  a  single  physical  line. 

Blocking  gives  scope  to  the  neuaes  used  to  identify  things. 
These  names  are  not  known  outside  the  scope  of  the  block  in  which 
they  are  defined. 

A  block  is  a  collection  of  statements.  Each  block  has  a 
particular  kind  of  statement  (called  a  block  header)  that  begins 
it.  All  blocks  are  explicitly  terminated  by  the  END  statement. 
Some  examples  of  blocks  are: 

SCHEMA  blockl; 

ENTITY  block2; 

ROLE 

a  :  REAL; 
b  :  INTEGER; 

END  * 

ENTITY  blocks; 

ROLE 

a  :  INTEGER; 
b  :  REAL; 

END; 

END; 

In  this  example  blockl  contains  blocks  and  blocks.  Since  the 
schema  block  is  always  the  outermost  block,  the  scope  of  its  name 
(blockl)  is  global.  The  two  entities  (blocks  and  blocks)  are  at 
the  same  level  and  their  names  must  be  different.  A  name  inside 
one  entity  block  may  be  the  same  as  a  name  in  the  other  entity 
block  as  in  the  example  sho%m.  The  attributes  a  and  of  blocks 
have  no  connection  with  the  attributes  a  Mnd  ^  of  blocks. 

A  statement  is  a  collection  of  tokens  (words,  literals, 
punctuation)  ending  with  a  semicolon  character. 

Tokens  make  up  the  basic  building  blocks  of  DSL.  All  tokens 
are  character  strings  that  observe  certain  formation  rules, 
always  based  on  the  first  character,  e.g.,  a  word  always  begins 
with  a  letter  of  the  alphabet,  and  no  other  token  begins  in  that 
manner . 
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2.  BASIC  LANGUAGE  ELEMENTS 
2.1  Character  Set 

A  schema  written  in  DSL  consists  of  a  string  of  characters, 
which  consists  of  letters  of  the  alphabet,  digits,  and  special 
characters. 

Letters 

A  to  Z  and  a  to  z 
Underscore 

_  (used  as  letter  except  as  first  letter  in  •a.  word) 


Digit? 

0  to  9 

Special  Characters 

+-*/•<>()  .  ,  :  ;  ‘11?  blank 
Compound  Symbols 

Certain  symbols  are  made  up  of  two  or  more  characters. 

<>  <-  >-  e*  II  —  (*  *)  AND  DIV  IN  LIKE  MOD  OR  RANGE 

No  distinction  is  made  between  upper  and  lower  case  letters 
except  when  they  appear  within  a  quoted  string. 

2.2  Reserved  Words 

Reserved  words  are  part  of  the  DSL  environment  and  may  not  be 
redefined,  i.e.,  used  as  identifiers.  Reserved  words  are 
classified  as  keywords,  standard  identifiers,  and  compound 
symbols. 
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2.2.1  Rewords 


ARRAY 

ASSOC 

AUTHOR 

BEGIN 

BY 

BETWEEN 

BOUND 

CASE 

DEFINE 

CLASS 

ELSE 

END 

ENTITY 

ENUMERATION 

ESCAPE 

FIXED 

FLOAT 

FUNCTION 

IF 

IS 

INPUT 

INTEGER 

KEY 

KEYROLE 

LIST 

LOCAL 

LOGICAL 

NOROLE 

NUMBER 

OF 

PROCEDURE 

OPERATION 

OTHERWISE 

RANGE 

ROLE 

RULE 

REFER 

REPEAT 

SCHEMA 

STRUCTURE 

SKIP 

STRING 

THEN 

TYPE 

TITLE 

TO 

UNTIL 

UPDATE 

VALUE 

VALUES 

VAR 

VARYING 

VERSION 

WHERE 

WHILE 

WITH 

2^2^.2  ■  Standard  Identifiers 

The  following  standard  identifiers  are  part  of  the  DSL 
environment  and  may  not  be  redefined. 

FALSE  TRUE 

2.2.3  Compound  Symbols 

Certain  operator  symbols  are  formed  from  letters  and  look 
like  words.  However/  they  might  just  as  well  have  been 
represented  as  combinations  of  special  characters.  The  compound 
sy^ols  are: 

AND  OIV  IN 

LIKE  MOO  OR 

RANGE 

2 . 3.  Program  Lines 

A  physical  line  ends  with  a  newline  character  (either  an 
explicit  character  or  combination  of  characters,  or  in  the  case 
of  fixed  length  records,  the  last  character  in  the  record) . 

A  single  word  or  literal  must  fit  entirely  in  a  physical  line. 
The  effect  of  this  is  that  the  limitations  of  the  implementation 
(with  respect  to  line  length)  determines  the  maximum  length  of 
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identifiers  and  other  elements  of  the  syntax.  Obviously,  the 
minimum  possible  line  length  must  be  greater  than  or  ecpial  to  the 
length  of  the  longest  reserved  word. 

3.  USER  DEFINED  lANGUAGE  ELEMENTS 

3.1  Identifiers 

An  identifier  is  a  string  of  characters  (a  word)  used  to  name 
some  element  of  the  schema.  The  first  character  in  the  string 
must  be  a  letter,  and  the  remaining  characters,  if  any,  must  be 
letters,  digits,  or  the  luiderscore  character. 

No  distinction  is  made  between  upper  and  lower  case  letters, 
e.g.,  POINT,  Point,  and  point  are  all  the  same  identifier. 

An  identifier  must  not  be  the  same  as  one  of  the  DSL  reserved 
words.  A  table  of  reserved  words  may  be  found  at  the  end  of 
Part  ZI  of  this  docxment. 

Some  examples  of  valid  and  invalid  identifiers  are: 

Y.ali4 

point 

line 

CenterOfGravity 

end__point^2 

loyalid 

abc  —  starts  with  underscore 

7end  — •  starts  with  digit,  not  letter 

continuity  flag  has  embedded  space 

3.2  Literals 

Literals  are  self  defining  constants  used  to  form 
expressions.  The  types  of  literals  permitted  by  DSL  are: 

Integer  Float 

Fixed  String 

Logical 

3.2.1  Integer  Literal 

is  a  string  of  digits.  A  unary  sign[+-]  operator  may  be  used 
to  negate  the  ntunber.  The  unary  operator  is  not  part  of  the 
literal  however. 
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3.2.2  Fixed  Literal 

is  em  Integer  literal  followed  by  a  decimal  point  and  an 
optional  integer  literal.  The  scale  of  the  fixed  nvunber  is  taken 
to  be  the  total  number  of  digits  in  the  number  and  the  precision 
is  taken  to  be  the  number  of  digits  to  the  right  of  the  decimal 
point.  A  unary  sign[+-]  operator  may  be  used  to  negate  the 
number .  The  unary  operator  is  not  part  of  the  literal  however. 


Examples 

of  valid  and  invalid  fixed  : 

valid 

-123.45 

scale«5 

precision*! 

0.01 

scale>3 

precision*! 

4.599999 

scale*? 

precision*6 

4. 

scale*l 

precision*0 

lPYall<^ 

-.45 

No  leading  digit 

4.  56 

Embedded 

blank 

Hot  fixed,  treated  as  integer 


/ 


3.2.3  Float  Literal 

is  an  integer  literal  followed  immediately  by  a  decimal 
point,  an  optional  integer  literal,  the  letter  fi,  and  an  integer 
literal  which  is  the  exponent.  Ho  spaces  are  permitted  within 
this  string.  A  unary  signC+-]  operator  may  be  used  to  negate  the 
number.  The  unary  operator  is  not  part  of  the  literal  however. 

The  first  part  (before  the  E)  defines  the  mantissa  of  the 
number.  The  last  part  (after  the  E)  defines  the  exponent. 

Examples  of  valid  and  invalid  float  literals  are: 


vaUcl 

-1.E16 

568.99E-3 

0.001E5 


-10000000000000000.0 

0.56899 

100.000 


invalid 

-1E16 

568.  99E-3 
-.001E5 


No  decimal  point 
Embedded  blank 
No  leading  digit 
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3.2.4  String  Literal 

is  any  string  of  characters  enclosed  by  single  quotes.  A 
string  literal  is  the  only  context  where  upper  and  lower  case 
letters  are  significant,  i.e.,  *ABC'  is  not  ec[ual  to  'abc'. 

If  a  single  quote  is  part  of  the  literal  it  is  written  twice. 
e.g. .  'John*  *s  doo*  is  interpreted  as  John's  dog. 

The  string  literal  nay  contain  escape  characters  to  represent 
special  syobols,  e.g.,  Xanji  or  natheaatical  symbols.  At  the 
present  the  escape  mechanism  is  not  defined. 

3.2.5  Logical  Literal 

is  either  the  word  TRUE  or  FALSE. 

3.3  Lexical  Substitution 

The  author  may  define  character  strings  to  be  substituted 
within  the  body  of  the  schema.  This  is  done  by: 

DEFINE 

fabc  *  any  text  you  wish  ; 

The  substitution  string  consists  of  the  first  significant 
character  through  the  last  significant  character  between  the 
equal  mark  and  the  semicolon  mark.  Kota  that  a  semicolon  may  not 
be  part  of  the  substitution  string.  In  this  example  the 
substitution  string  is:  anv  text  vou  wish . 

ENTITY  qwerty; 

#abc  ; 

Each  time  #abc  is  seen  it  is  replaced  by  the  text  defined  in 
the  DEFINE  block.  Note  that  this  is  a  simple  text  substitution 
and  no  checks  are  made  (at  the  time  of  the  stibstitution)  for 
correctness.  However,  when  the  substituted  text  is  processed,  any 
errors  will  be  flaged. 

The  example  would  yield: 

ENTITY  qwerty; 

any  text  you  wish  ; 

which,  of  course,  would  produce  an  error  when  it  is 

processed. 

Substitution  does  not  take  place  within  string  literals,  or 
within  comments.  Thus, 


a  *  'fabc* ; 
or 

(*  fabc  *) 

would  not  produce  a  s;ibstitution. 
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3.4  Coauaentg 

Cosunents  aay  be  used  to  docxment  the  scheaa.  The  entire 
coaaent.  Including  the  (*,  *) ,  or  —  syabola  are  ignored.  They 
aay  be  written  in  two  ways. 

Embedded  coaaents  follow  the  fora: 

(*  anything  you  wish  to  say  *) 

(with  the  exception  of  *)  which  must  not  be  part  of  the  ccaaent) , 
and  tail  comments  follow  the  fora: 

anything  you  wish  to  say  <newline> 

Embedded  coaaents  aay  be  %rritten  any  place  a  blaxOc  character 
is  permitted  and  is  treated  as  a  blanJc. 

Tail  coaaents  aust  appear  at  the  end  of  any  significant  part 
of  a  statement  as  the  doxible  hyphen  and  all  of  the  remaining 
characters  on  the  same  physical  line  are  ignored. 

4.  SCHEMA 

The  schema  is  everything  known  about  some  enterprise  of 
interest.  Zt  includes  entitles,  classes,  rules  (and  other 
algorithms) ,  and  operations.  Zt  is  expressed  in  a  way  that  is 
independent  of  possible  implementations.  Zt* is  structural,  but 
not  structural  in  the  sense  of  a  given  implementation,  i.e.,  the 
mapping  of  relational  tables  from  the  scheaa  will  yield  an 
entirely  different  structure. 

A  schema  is  written  as: 

SCHEMA  schema-name; 

—  type  declarations 
-*»  entity  declarations 
-**  class  declarations 
**«  rule  declarations 

—  etc. 

END; 

The  elements  of  the  schema  must  be  defined  before  they  are 
referenced,  except  that  entities  aay  make  forward  references  to 
classes  and  vice  versa. 

Each  element  of  the  scheaa  aust  have  a  name  that  is  different 
than  every  other  name  known  to  the  schema,  e.g.,  if  there  is  an 
entity  named  point  there  nay  not  be  a  class  named  point. 
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5^ _ entity 

An  entity  is  an  abstraction  of  something  about  which 
information  is  to  be  kept.  Generally  speaking  an  entity 
represents  some  artifact.  An  entity  is  made  up  of  a  set  of 
attributes  which  are  the  facts  about  it.  Each  attribute  has  a 
name  and  a  semantic  type.  Attributes  may  also  have  either  static 
or  dynamic  constraints.  These  constraints  define  the  set  of 
values  that  are  permissible  for  a  given  fact. 

The  names  of  attributes  must  be  unique  within  the  scope  of 
the  entity  in  which  they  are  declared.  Attribute  names  do  not 
have  to  be  unique  within  the  schema.  The  name  of  an  entity  may  be 
the  same  as  the  name  of  one  of  its  attributes  (since  the  entity 
is  in  the  scope  of  the  schema,  while  the  attribute  is  in  the 
scope  of  an  entity).  Thus: 

ENTITY  a; 

a  :  integer; 

END; 

is  permissible  (although  perhaps  poor  style) . 

Attributes  are  classified  either  as  role,  norole,  or 
associative  (assoc) . 

A  role  attribute  is  an  essential  fact  about  the  entity. 
Without  it  the  meaning  of  the  entity  is  impossible  to  determine. 

A  norole  attribute  exists  only  for  the  purpose  of  supporting 
some  implementation.  A  norole  attribute  could  be  removed  from  the 
declaration  without  affecting  the  meeming  of  the  entity. 

An  associative  attribute  defines  a  special  relationship 
between  two  or  more  other  entities.  All  associative  attributes 
must  be  of  the  semantic  type  refer.  Like  role  attributes, 
associative  attributes  are  necessary  for  understanding  although 
they  are  not  strictly  part  of  the  definition  of  the  entity. 

An  entity  is  written: 

ENTITY  entity-name  [WHERE  constraint] ; 

NOROLE 

—  norole  declarations 

ROLE 

—  role  declarations 

ASSOC 

—  association  declarations 

END; 

The  different  kinds  of  declarations  may  be  given  in  any 
order . 
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An  attribute  is  declared  as: 

attribute-name  :  semantic-type  [WHERE  constraint] ; 

See  Section  8  for  a  discussion  of  semantic  types.  The 

constraint  is  optional.  When  given,  a  combination  of  static  and 

dynamic  constraints  may  be  specified.  See  Section  9  for  static 

constraints. 

examples: 

1  ENTITY  point; 

2  NOROLE 

name  :  STRING; 

3  ROLE 

x,y,2  :  REAL; 

4  END; 

5  ENTITY  line 

WHERE  disjoint (defining__poeition  l,defining_position  2)  ; 

6  NOROLE  ” 

name  :  STRING; 

7  ROLE 

defining_poaition  1  ;  REPER(point) ; 

defining_po8ition~2  :  R£FER(point) ; 

8  END; 

1)  begin  definition  of  entity  called  'point*. 

2)  begin  norole  declarations,  i.e.,  'name*  which  is  a  string 
semantic  type. 

3)  begin  role  declarations.  This  also  ends  the  norole 
declarations.  x,y,z  are  the  names  of  the  role  attributes 
all  of  which  are  of  the  semantic  type  real. 

4)  ends  the  entity  definition. 

5)  begin  definition  of  entity  called  *line'.  The  where  clause 
calls  for  a  dynamic  rule  (not  shown)  that  says  the  two 
defining  points  of  a  line  must  be  disjoint. 

6)  begin  norole  declarations,  i.e.,  'name'  which  is  a  string 
semantic  type. 

7)  begin  role  declarations.  This  also  ends  the  norole 
declarations.  defining__position  1  and  defining  position  2 
are  both  references  to  a  point  X*ntity) .  An  alternate  “ 
definition  strategy  is  sho%m  following.  This  definition 
says  that  the  defining  points  may  be  shared  (i.e.,  used  in 
the  definition)  by  other  entities. 

8)  ends  the  entity  definition. 
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Alternatft  Dafinltion  of  Line 


9 


ENTITY  line 

WHERE  disjoint (defining__position  l,defining_position_2)  ; 
NOROLZ  " 

name  :  STRING; 

ROLE 

defining_position_l  :  point; 
defining_po6ition  2  :  point; 

END;  “ 


9)  here  ve  define  line  by  two  points,  not  references  to 

points.  This  says  that  the  two  defining  points  nay  not  be 
used  by  other  entities.  This  definition  has  a  stronger 
sense  of  dependence  than  the  case  given  next.  The  sane 
disjoint  rule  would  apply  just  as  in  the  other  case. 

fNTITY  line 

WHERE  disjoint (defining_position  l,defining_position_2) ; 

NOROLE 

nane  :  STRING; 

10  ROLE 

defining  positional  ;  DEPENDENT  REFER (point) ; 

defining_position“2  :  DEPENDENT  REFER (point) ; 

END; 


10) 


here  we  define  by  references  to  point,  but  say  the  points 
nay  be  shared  (since  there  is  an  instance  of  each  point, 
they  may  be  referenced  by  anything) .  However,  if  we 
delete  an  instance  of  line,  we  nust  also  attenpt  to 
delete  both  instances  of  point.  This  attenpted  delete  may 
or  nay  not  be  possible  depending  on  how  those  two  points 
are  otherwise  used. 


6.  CLASS 

A  class  defines  a  grouping  of  things  that  are  thought  to  be 
aliXe  in  some  nemner.  When  reference  is  Bade  to  a  class  it  means 
that  any  neaiber  of  that  class  will  satisfy  the  reference,  e.g. , 
if  we  define  the  class: 

CLASS  fruit; 

OF  (apple,  orange) ; 

END; 

and  then  aaXe  reference  to  lEiiSL#  ve  are  saying  that  either  app.le 
or  orange  is  a  pernissible  reference.  A  class  is  a  good  way  to 
Bix  apples  and  oranges  so  to  speaJc. 
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A  class  may  hav«  other  classes  as  members.  We  could  define: 
CLASS  tart_fruit; 

OF  (lemon,  grapefruit,  cratnberry) ; 

END; 


and 


CLASS  sweet  fruit; 

OF  (pear, ""strawberry,  apple)  ; 

END; 

and  then: 

CLASS  fruit; 

OF  (tart  fruit,  sweet_fruit) ; 

END; 

A  class  is  defined  by  the  bloclc: 

CLASS  class-name; 

OF  (member-list) ; 

END; 

Class-name  is  a  valid  identifier  which  names  the  class  being 
defined.  The  member-list  is  a  list  of  names  of  classes  or 
entities,  that  are  members  of  the  class  being  defined.  Each 
member  in  the  list  is  separated  by  a  comma  and  each  member  must 
be  of  the  same  type  (i.e.,  they  all  must  be  classes,  or  entities, 
etc. ) . 

Zi _ algorithms 

DSL  provides  for  four  hinds  of  algorithm  definitions.  A 
procedure  is  a  general  algorithm  which  performs  some  sequence  of 
operations.  A  fxinction  is  a  procedure  that  yields  a  particular 
result  which  may  be  either  a  simple  type  or  a  complex  type.  A 
rule  is  a  special  kind  of  f\inction  that  yields  only  a  true  or 
false  result.  An  operation  is  a  way  of  expressing  a  result  in 
infix  or  prefix  style.  It  is,  in  fact,  a  way  of  extending  the  set 
of  built-in  operators  of  the  language. 
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7.1  Procedure 

A  procedure  is  written  in  the  sane  manner  as  ordinary 
procedural  languages.  The  general  fom  of  the  procedure  block  is: 

PROCEDURE  proc  name(  forma l^parameters  }  ; 

LOCAL 

any  local  declarations  go  here 
BEGIN; 

body-of-procedure 

END; 

A  procedure  is  invoked  by  the  call: 
proc_^name(  actual*“parameters  )  ; 

The  nxunber  and  type  of  the  actual  parameters  and  formal 
parameters  must  match  exactly.  A  procedure  may  be  written  without 
formal  parameters,  in  which  case  the  procedure  header  and 
invocation  would  look  like: 

PROCEDURE  proc  name ( ) ; 

BEGIN; 

END; 

proc_name ( ) ; 

That  is,  the  left  and  right  parentheses  are  not  optional. 

7.2  Function 

A  fiinction  is  a  procedure  that  produces  the  specified  result 
type.  The  result  type  may  be  simple  or  complex.  The  invocation 
of  a  function  is  exactly  equivalent  to  writing  a  variable  of  the 
given  type  in  an  expression. 

7. 3 _ Rule 

7.4  Operation 

Built-in  operations  such  as  add,  subtract,  multiply,  and 
divide  are  commonly  written  as: 

[1]  a  +  b  *  c  /  d 
but  could  also  be  %rritten: 

[ 2 ]  add ( a , divide (multiply (b , c) , d) ) 

taking  into  account  the  usual  hierarchy  of  operation. 
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Whichever  style  is  used  depends  somewhat  on  individual 
preference  and  accepted  practices.  We  (most  of  us)  would  prefer 
to  see  the  arithmetic  expression  %n:itten  as  style  [1]  instead  of 
style  [2]. 

The  operation  construct  allows  for  extension  of  the  built-in 
set  of  operations  such  that  the  written  language  reflects  the 
style  that  is  most  natural  to  the  user  community. 

An  operation  is  %#ritten: 

OPERATION  infix (id: type;  symbol;  id: type) ; type; 

BEGIN ; 

END; 


-or- 

OPERATION  unary ( symbol ;  id : type) ; type ; 

BEGIN; 

END; 

where : 

infix  or  unary  are  the  names  given  to  the  operation  being 
defined  (actually  names  like  add,  invert#  cross#  ace,  etc. 
would  be  used.  Infix  and  \inary  refer  to  the  characteristic 
of  the  operation  itself) . 

type  is  either  the  input  or  result  obiijects,  which  may  be 
simple  objects  such  as  numbers  or  strings^  or  complex  objects 
such  as  entities.  Id  the  local  identifier  of  the  object 
for  reference  within  the  algorithm. 

symbol  is  a  string  literal  that  defines  a  new  reserved  word. 
Even  though  it  is  written  as  a  string  the  following 
restrictions  apply: 

—  no  embedded  blanks  are  permitted 

—  the  first  character  must  be  a  letter  [A. .Z,  a..z] 

—  the  remaining  characters  must  be  letters,  digits,  and 
underscore 

—  the  symbol  becomes  part  of  part  of  the  DSL  environment  and 
has  global  scope. 

Once  an  operation  has  been  defined  it  may  be  used  in  the  same 
manner  as  built-in  operations.  First  vector  dot  product  and 
vector  cross  product  operation  will  be  defined,  then  they  will  be 
referenced  to  illustrate  this  construct. 
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ENTITY  vector; 

ROLE 

:  FLOAT; 

END; 

OPERATION  vector  dot^product (a: vector, * dot* ,b: vector) 

;  real;  “ 

LOCAL 

c  :  real; 

BEGIN; 

c  -  a.i  *  b.i  +  a.j  *  b.j  +  a.lc  *  b.k; 
vector_dot__product  -  c; 

END;  “ 

OPERATION  vector_^cross_product (a: vector,  'cross*  ,b: vector) 
;  vector;  “ 

LOCAL 

c  :  vector; 

BEGIN; 

~  body  of  procedure 
vector  dotjproduct  ■  c; 

END;  “ 


PROCEDURE  some  name; 

LOCAL 

vl,  v2,  v3,  v4  :  vector; 
dotpr  :  real; 

BEGIN; 


dotpr  -  v2  dot  v3 ; 

operations  are  processed  left  to  right,  thus: 
vl  ■  v2  cross  v3  cross  v4; 

is  the  same  as: 
vl  •  (v2  cross  v3)  cross  v4; 

<—  nesting  may  be  used  to  alter  the  left  to  right  order 
vl  >  v2  cross  (v3  cross  v4} ; 


END; 

7.5  Expressions 

Expressions  are  constructs  giving  rules  for  the  computation 
of  values.  They  consist  of  operands:  variables,  literals,  and 
function  invocations,  combined  by  operators  as  explained  in  the 
following  paragraphs. 
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Each  operator  has  a  priority  which  detemines  when  a 
particular  subexpression  is  evaluated. 

1.  Exponentiation  Prefix-  Prefix+  Not 

2.  Multiplication  Division 

3 .  Addition  Subtraction 

String  Concatenation 

4.  Relational 

5.  And 

6.  Or 

Expressions  are  evaluated  fron  left  to  right  talcing  into 
account  toe  priority  of  each  operator,  i.e.,  each  subexpression 
of  priority  1  is  evaluated  from  left  to  right;  then  each  sub¬ 
expression  of  priority  2  is  evaluated  in  toe  same  manner;  etc. 
until  toe  entire  expression  is  finished. 

6  .Built-in  Functions 

A  niimber  of  conceptual  fiinctions  are  built  into  toe  DSL 
environment  to  operate  on  numbers,  strings,  etc. 

Number  Functions 

ABS(n) 

COS(n) 

SlN(n) 

TAH(n) 

LOG(n) 

LOG10(n} 

SQRT(n) 

SQUARE (n) 


8.  Semantic  Types 

Semantic  types  are  to  information  modeling  as  data  types  are 
to  data  modeling.  In  data  modeling  we  are  concerned  with  toe  form 
and  character  of  data.  In  infoirmatlon  modeling  we  are  concerned 
with  toe  abstract  representation  of  information. 

To  illustrate  this  difference  consider;  in  information 
modeling  the  notion  of  integer  is  simply  that  of  a  whole  number. 
There  is  no  assumption  about  how  that  whole  number  might  be 
represented.  In  data  modeling  we  become  concerned  with  toe 
details  of  implementation,  e.g.,  do  we  use  twos  complement  binary 
representation  using  four  bytes?  do  we  use  numeric  characters?  do 
we  use  packed  decimal  format?  and  so  forth.  As  a  practical  matter 
toe  difference  between  data  type  and  semantic  type  is  probably 
not  important. 
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DSL  supports  the  following  semantic  types: 


Number  — — — \ 

Integer  | --Simple  types 

Real  I 

Fixed  I 

Float  I 

String  I 

Logical - — -/ 

Array - — — \ 

List  1  —Grouping  type 

Set - / 

Refer - Relational  type 

Defined  ———Extension  type 

Structiire  —\— Complex  types 
Enumeration  — -/ 


The  simple  types  correspond  to  the  data  types  found  in  almost 
every  programming  language  or  database  management  system.  The 
grouping  types  provide  for  homogeneous  grouping  of  other  semantic 
types  (including  perhaps  grouping  types).  The  relational  type 
provides  for  forming  relationships  between  things.  The  extension 
type  provides  for  an  extension  of  the  set  of  semantic  types. 
Complex  types  provide  for  heterogeneous  groupings  or  arbitrary 
naming  of  values.  The  complex  types  must  be  treated  as  extensions 
of  the  semantic  type  set,  i.e.,  they  may  not  be  used  directly  by 
attributes. 

In  all  of  the  examples  the  attribute  declaration 

example  :  semantic-type; 

will  serve  as  an  example  to  show  the  proper  usage  each  semantic 
type. 

8.1  Simple  Types 

Kxomber 

Integer 

Real 

Fixed 

Float 

String 

Logical 
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Kuiwber  is  an  abstraction  of  integer  or  real.  It  is  an  inexact 
specification.  It  is  used  when  the  exact  specification  is 
unJcnovn,  i.e.,  it  is  not  Icnown  yet  whether  an  attribute  is 
integer,  fixed,  or  float. 

example  :  number; 

Integer  defines  an  attribute  to  be  a  whole  number  either 
signed  or  \insigned.  This  is  an  exact  specification.  An  optional 
precision  may  be  specified  along  with  the  integer  specification. 
If  no  precision  is  given  the  integer  is  assumed  to  have  an 
indefinite  number  of  (decimal)  digits.  If  the  precision  is 
provided  the  value  of  the  integer  has  an  implied  constraint  on 
the  values  an  instance  of  the  attribute. 

example  :  integer; 
example  :  integer (p) ; 

where  p  is  an  unsigned  integer  literal. 

Peal  is  an  abstraction  of  either  a  fixed  or  a  float  number. 

It  is  an  Inexact  specification  which  is  used  when  it  is  not  known 
whether  the  exact  type  is  fixed  or  float. 

example  :  real; 

Fixed  is  a  number  that  has  an  exact  or  implied  precision  and 
resolution.  The  precision  is  the  number  of  decimal  digits  in  the 
number  and  the  resolution  is  the  number  of  digits  to  the  right  of 
the  decimal  point.  Fixed  nximbers  would  eoiamonly  be  used  for  money 
transactions  for  instance.  A  fixed  number  may  be  specified: 

example  :  fixed; 
example  :  fixed(,r); 
example  :  fixed(p,r); 

where  p,r  are  both  unsigned  integer  literals. 

Float  is  a  number  that  has  an  exact  or  implied  mantissa 
precision  and  an  exponent  value  of  arbitrary  magnitude.  It  is 
commonly  used  for  scientific  calculations.  A  float  number  may  be 
specified: 

example  :  float; 
example  :  float (p) ; 

where  p  is  an  unsigned  integer  literal  which  defines  the  minimum 
number  of  decimal  digits  in  the  mantissa. 
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String  is  a  sequence  of  characters,  which  are  normally 
printable.  A  string  would  be  used  to  represent  a  persons  name, 
address,  etc.  A  string  may  also  hold  special  non-printable 
characters  which  are  used  to  control  a  printer  or  to  represent 
special  symbols  such  as  those  used  in  mathematical  formulas  or 
those  needed  for  non-English  alphabets  (e.g.,  Kanji) . 

example  :  string; 
example  :  stringCl); 

where  1  is  an  unsigned  integer  literal  which  defines  the  maximimi 
length  in  characters  of  a  particular  string.  Note  that  I 
corresponds  to  the  number  of  characters,  not  the  niimber  of  units 
of  storage  needed  to  represent  the  string  value,  e.g.,  a  single 
Kanji  character  may  occupy  two  bytes  of  storage. 

Logical  represents  the  states  True  or  False.  This  is  often 
called  a  Boolean  value.  It  is  specified  as: 

example  :  logical; 


8,2  grouping  Tvrgg 

Array 

List 

Set 

The  grouping  types  provide  for  homogeneous  groupings  of 
semantic  types. 

Array  is  a  homogeneous  group  that  has  a  defined  lower  and 
upper  bound,  which  must  be  integer  values,  ^e  lower  bound  must 
be  less  than  or  equal  to  the  upper  bound.  Given  that  L  is  the 
lower  bound  and  U  is  the  upper  bound,  then  there  are  exactly 

cr  -  L  elements  in  the  array. 

List  is  an  ordered  homogeneous  grouping  that  has  a  defined 
lower  bound,  but  a  possibly  indefinite  upper  boxind.  The  lower 
bound  specifies  the  minimum  number  of  elements  that  are  required 
to  be  in  the  list.  This  lower  bound  must  be  an  integer  which  is 
zero  or  greater. 

Set  is  an  unordered  homogeneous  grouping  that  has  a  defined 
lower  bound,  but  a  possibly  indefinite  upper  bound.  The  lower 
bound  specifies  the  minimum  number  of  elements  that  are  required 
to  be  in  the  set.  This  lower  bound  must  be  an  integer  which  is 
zero  or  greater.  A  set  is  similar  to  a  list  with  this  exception: 
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Thtt  order  of  the  elements  in  a  list  are  significant.  The 
order  of  the  elements  in  a  set  are  not  significant.  Thus,  if 
we  had: 

ENTITY  group; 

R01£ 

member  :  set(0  to  ?)  of  refer (geometry) ; 

END; 

we  would  assTime  no  significance  by  the  order  or  position  of 
one  element  of  the  set.  But  if  we  had: 

ENTITY  loop; 

ROLE 

member  :  list (2  to  ?)  of  refer (edge) ; 

END; 

the  position  of  one  edge  within  the  list  is  significant, 
i.e.,  the  edges  must  be  ordered. 

9.  STATIC  CONSTRAINTS 

A  Static  constraint  specifies  the  values  that  a  simple 
semantic  type  can  (is  permitted  to)  attain.  Static  constraints 
may  be  ranges  of  values,  discrete  values,  or  value  boxinds.  This 
does  not  preclude  the  use  of  rules  when  specifying  static 
constraints.  It  is  recommended  that  rules  be  used  when  there  are 
a  number  of  static  constraints  on  a  particular  semantic  type. 

9.1  RANGE  is  used  to  Constrain  values  to  a  discrete  range.  For 
example,  an  integer  number  is  valid  only  if  it  has  the  values 
1  thru  10.  The  specification  allows  for  inclusive  and/or 
exclusive  ranges.  The  specification  format  is: 

RANGE  (  lo-value  <  value  <  hi-value  ) 

RANGE  (  lo-value  <-  value  <  hi-value  ) 

RANGE  (  lo-value  <  value  <•  hi-value  ) 

RANGE  (  lo-value  <■  value  <•  hi-value  ) 

lo-value  and  hi-value  must  be  literals  and  must  correspond  to 
the  semantic  type  which  preceeds  this  specification.  The  semantic 
type  may  be  any  simple  semantic  type  except  for  logical,  lo-value 
must  be  less  than  hi-value. 

Note  that  value  is  a  keyword  which  eqpiates  to  the  name  of  the 
attribute  being  constrained. 

examples: 

X  :  real  range (0  <  value  <  100); 

This  reads:  x  is  a  real  number  which  must  satisfy  the 
condition  0<x<100  (zero  is  less  than  x,  and  x  is  less  than  100) . 
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1  t  integer  ranged  <  value  <»  10)  r 

This  reads:  i  is  an  integer  nvmber  which  must  satisfy  the 
condition  l<i<«10  (1  is  less  than  i,  and  i  is  less  them  or  equal 
to  10} .  Since  integers  have  a  discrete  resolution  this  could  also 
be  %nritten  as: 

1  :  inteaerfl  <«  value  <  11) ? 

with  no  loss  of  meaning.  Note  that  this  is  only  possible  with 
integer  and  fixed  semantic  types.  Kxunber,  real,  and  float  are 
assumed  to  have  an  unlcnown  resolution. 

s  :  strinaf4}  ranoePA*  <■  value  <■  *2222*)? 

The  value  of  s  must  satisfy: 

if  *A'  <■  s  then 
if  s  <•  *Z22Z'  then 
result  :«  true; 

This  ass\imes  that  if  the  two  comparands  are  of  different 
lengths  the  shorter  is  padded  on  '^e  righu  with  blanlcs  to  the 
length  of  the  longer  before  the  comparison  is  made.  The  result  of 
the  comparison  will  depend  on  the  character  set  being  employed  - 
ASCII,  EBCDIC,  etc. 

9.2  BOUND  defines  a  value  half  space,  e.g.,  only  the  values 
greater  than  10  are  va.lid  for  a  given  semantic  type.  The 
specification  follows  the  form: 

BOUND  (  value  rel-op  constant  ) ; 
where  rel-op  must  be  one  of: 

<<■>>• 

The  relational  operators  (equal)  and  <>  (not  equal)  are  not 
permitted  in  this  context.  The  constant  must  correspond  to  the 
declared  semantic  type  which  preceeds  this  specification. 


examples: 
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9.3  VALUES  defines  a  set  of  discrete  values.  Each  of  the  discrete 
values  must  correspond  to  the  declared  semeintic  type.  The 
specification  follows  the  form: 

VALUES  (  constant,  constant,  ...  }; 

where  each  constant  must  correspond  to  the  declared  semantic  type 
which  preceeds  this  specification. 

examples: 


The  specification  of  static  constraints  can  help  to  define 
the  context  and  use  of  an  attribute  declaration.  These 
specifications  do  not  suggest  how  the  implementation  might 
enforce  the  constraint,  only  that  the  constraint  must  be  enforced 
somehow. 

More  than  one  static  constraint  may  be  applied  to  a  single 
attribute,  e.g. , 


Kote  that  static  constraints  can  be  used  to  determine  the 
minimum  storage  required  for  certain  semantic  types.  Zn  the 
previous  case  it  is  obvious  that  the  total  range  of  values  is 
1  through  255,  but  with  some  gaps.  This  value  can  be  held  in  a 
single  byte  of  memory.  But  consider  the  following: 


This  is  a  conflict  because  the  precision  specification  is  not 
compatible  with  the  range;  one  says  that  y  can  hold  the  values 
-999  through  999  while  the  other  says  the  values  can  range  from 
0  through  1000.  Other  conflicts  or  confusion  can  result  from 
mixed  specification,  e.g.. 


This  is  confusing.  It  either  says  £  can  have  any  value  less 
than  zero  or  any  value  between  10  and  100000.  Or  it  can  be 
interpreted  as  saying  that  £  must  be  both  less  than  zero  and  also 
between  10  and  100000  which  is  of  course  nonsense.  To  avoid  this 
possible  confusion  in  interpretation  mixing  of  bound  and  range  is 
not  permitted.  A  rule  could  be  written  to  handle  that  case. 

But  what  about  a  case  such  as  the  following. 
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a  :  Integer  range f0<value<100)  range f40<value<30m ? 

A  particular  value  of  a,  say  35,  would  satisfy  the  first 
specification  but  not  the  second.  The  strategy  in  this  case  is  to 
issue  a  warning  and  reduce  the  specification  to  a  cosunon  range. 

a  :  integer  range f0<value<3 00) ? 
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"When  I  use  a  word,"  Nuapty  Dumpty  said  in 
rather  a  scornful  tone,  "it  aeans  just  what  I 
chose  it  to  Bean  •  neither  aore  nor  less." 

froa  "Through  the  Looking  Glass" 
by  Lewis  Caroll 

1-NF,  2>NF,  etc .  The  technique  of  organizing 

attributes  into  records  such  that 
BaxiauB  stability  in  the  developed 
structures  is  achieved. 

?  (OPEN  UPPER  BOUND)  . Used  to  specify  a  to-aany 

relationship. 

APPLICATION . A  set  of  procedural  or  non¬ 

procedural  code  used  to  accoaplish 
soae  end  state. 

ARRAY  SEMANTIC  TYPE . An  ordered  collection  of  some 

seaantic  type  having  a  fixed  lower 
and  upper  bound  (index) . 

ATTRIBUTE  . A  fact  about  an  entity. 

BACK  POINTER . A  physical  iapleaentation  that 

accounts  for  the  users  of  a  given 
entity. 

A  way  of  accoaplishing  a 
aany-to-aany  relationship. 


BN?  .  Bachas-Nauer  Form  (or  Bachas-Normal 

Form) .  A  aethod  of  expressing  the 
graaaar  of  a  language. 

CARDINALITY  .  The  number  of  entities  involved  in  a 

given  relationship. 

CLASS  . A  collection  of  entities  that  are 

(thought  to  be)  aliJce  in  soae 
aeuiner. 

CONCEPTUAL  SCHEMA . See  AN5I/X3/SPARC  DBSG 

CONSTRAINTS  . A  Condition  of  any  kind  which  aust 

be  enforced  on  values  of  attributes. 


COLLECTION  SEMANTIC  TYPE  ...  A  semantic  type,  similar  to  list, 

which  requires  that  all  eleaents  are 
of  the  same  kind. 
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DATA . 

DATA  MODEL  . 

DBMS  . 

DEFINED  SEMANTIC  TYPE  . 

DEPENDENT  . 

DISCIPLINE  . 

DISCOVERY  . 

ENTERPRISE  . 

ENTITY  . 

ENUMERATION  SEMANTIC  TYPE  .. 

ENVIRONMENT  . 

EXCHANGE  . 


Tha  representation  of  Infomation 
independent  of  its  meaning,  e.g.,  an 
Integer  number. 

A  method  of  expressing  the  data 
content  and  relationships  of  a  data 
processing  system. 

DataBase  Meinagement  System 

A  semantic  type  that  is  defined  by 
the  schema  author.  An  extension  to 
the  built<-in  semantic  types. 

A  relationship  attribute  which 
stipulates  that  the  referenced 
entity  exist  only  for  the  purpose  of 
defining  the  refering  entity. 

A  branch  of  knowledge  or  training. 

The  identification  of  Information 
needed  by  an  enterprise. 

A  business,  or  a  significant  segment 
of  a  business. 

A  thing  of  interest  about  which  data 
is  to  be  kept. 

An  ordered  collection  of  values,  any 
one  of  which  being  the  value  of  an 
attribute  of  that  type  at  a  given 
Instant. 

The  total  of  circumstances 
surrounding  a  system,  specifically: 
the  combination  of  external  or 
extrinsic  physical  conditions  that 
affect  the  behavior  of  a  system 

The  process  of  moving  information 
from  one  environment  to  another. 


EXTERNAL  SCHEMA . See  ANSI/X3/SPARC  DBSG. 

FIXED  SEMANTIC  TYPE . A  real  number  which  has  a  defined 

precision  (total  number  of  digits) 
and  resolution  (number  of  digits  t 
the  right  of  the  decimal  point) . 
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FLOAT  SEMANTIC  TYPE . A  real  number  which  has  a  defined 

precision  (total  number  of  digits  in 
its  mantissa)  and  am  exponent. 

FUNCTION  .  An  algorithm  which  yields  some 

result  object. 

INDEPENDENT . A  relationship  attribute  that 

stipulates  that  the  referenced 
entity  may  exist  without  the 
existence  of  the  refering  entity. 

INFORMATION  .  Data 'plus  the  meaning  connected  with 


It.  It  is  any  kind  of  knowledge 
about  things  or  concepts  that  is 
exchamgeable  among  users,  e.g.,  an 
integer  number  is  the  age,  in  years, 
of  some  person.  dataOsase 

INFORMATION  MODEL  .  Nhat  STEP  calls  the  schema. 

The  process  of  formalizing  the 
structtire  and  semantics  of  data; 
i.e.,  information. 

INSTANCE . An  individual  entity  in  a  physical 

datadsase. 

INTEGER  SEMANTIC  TYPE  .  A  whole  number. 

INTERNAL  SCHEMA . See  ANSI/X3/SPARC  DBSG. 

KEY . An  attribute  that  is  used  to 

identify  an  instance  of  an  entity. 

LIST  SEMANTIC  TYPE . An  ordered  collection  of  a  given 

semantic  type  which  may  contain 
zero,  one,  or  more  elements.  Similar 
to  ARRAY,  but  may  not  have  a 
negative  lower  bound  amd  the  upper 
bound  may  be  indefinite. 

LOGICAL  SEMANTIC  TYPE . A  semantic  type  which  has  only  the 

values  True  and  False. 

MANDITORY  .  A  relationship  attribute  that 

stipulates  that  a  value  is  manditory 
(not  optional) . 
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MANY-to-MANY . A  kind  of  cardinality  that  allows  an 

indafinite  number  of  entities  on 
either  side  of  the  relationship.  Not 
usually  permitted  by  data  models; 
not  permitted  by  this  information 
modeling  technique.  See  back 
pointer. 

MAPPING  FUNCTION . .  A  function  that  transforms  one 

schema  to  another  schema,  or 
transforms  the  instances  of  entities 
defined  by  one  schema  to  instances 
defined  by  another  schema.  A 
translator. 

NOROLE . An  attribute  that  is  not  needed  for 

the  meaning  of  an  entity. 

NUMBER  SEMANTIC  TYPE . A  semantic  type  representing  any 

number  format:  integer,  real,  fixed, 
or  float. 

ONE-to-KANY  . . A  cardinality  where  one  entity  is 

related  to  zero,  one,  or  many  other 
entities. 


ONE-to-ONE  . A  cardinality  where  one  eatity  is 

related  to  exactly  one  other  entity. 

OPERATION . An  action  that  may  be  applied  to  an 

entity  which  yields  a  known  result. 

OPERATION  SET  . A  set  of  operations  that  apply  to  a 

specific  entity  or  class. 

OPTIONAL . A  relationship  attribute  that 

stipulates  that  an  attrpsute  value 
may  be  non-existant.  This  does  not 
imply  that  the  value  is  unknown. 

PROCEDURE  .  An  algorithm  which  operates  on 

information  to  produce  some  desired 
end  state. 

PROVIDER  .  The  person  or  system  that  provides 

information  to  (for)  the  receiver. 

REAL  SEMANTIC  TYPE . A  semantic  type  of  which  fixed  and 

float  are  s\ib-types. 

RECEIVER  .  The  person  or  system  that  receives 

information  from  the  provider. 
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REFER  SEMANTIC  TYPE 
REFERENCE  . 

RELATIONAL  TABLE  .. 

RELATIONSHIP  . 

ROLE  . 

RULE  . 

SCHEMA  . 


SEMANTIC  TYPE  . 

SET  SEMANTIC  TYPE  . 

STRING  SEMANTIC  TYPE  . 

STRUCTURE  SEMANTIC  TYPE  .... 

SYSTEM  . 


A  semantic  type  used  to  establish  a 
relationship. 

An  instance  of  a  relationship 
between  two  entities.  The  aechanisn 
for  establishing  this  link  is 
inplementation  dependent. 

One  kind  of  data  aodel  in  which  data 
is  arranged  into  columns  and  rows. 

A  mechanism  used  to  connect  (link) 
two  entities  in  some  fashion. 

An  attribute  that  is  necessary  for 
the  meaning  of  an  entity  to  be 
complete. 

A  constraint  which  must  be  enforced 
by  the  information  processing 
system. 

A  description,  or  definition,  of  the 
data  elements  of  interest  to  am 
enterprise.  The  schema  may  be  cast 
as  conceptual,  external,  or 
internal. 

It  is  what  ve  call  the  the 
information  model.  It  embodies  what 
ve  (think  ve)  know  about  enterprise 
information. 

An  abstraction  of  the  physical 
representation  of  an  attribute, 
i.e.,  the  vay  ve  think  of  the 
realization  of  data. 

A  semantic  type,  similar  to  list,  in 
vhich  the  order  of  elements  is  not 
meaningfxil . 

A  sememtic  type  representing  an 
ordered  list  of  characters,  i.e., 
letters,  digits,  special  characters. 

A  semantic  type  vhich  is  a  set  of 
attributes  that  together  have  a 
meaning. 

A  computer  system. 


IV-5 


ISO/TC184/SC4/WGl:4.1.I  (DRAPT) 
DATA  SPECIFICATION  LANGUAGE 


14  MAR  1986 
PART  rr  —  GLOSSARY 


STEP.. 

TRANSLATOR 


A  napping  function.  The  application 
that  accomplishes  translation  from 
one  schema  to  another. 


Paper  On  PDES 
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THE 

PRODUCT  DATA  EXCHANC3E  STANDARD 

(pk:s) 


BY 

J.  C.  KELLY 

SANDIA  NATIONAL  LABC»ATC«IES 
CHAIRMAN,  PDES  LOGICAL  LAYER  INITIATION  TASK 


PDES  SCOPE  AND  OBJECTIVES 


PDES  stands  for  Product  Data  Exchange  Standard.  A  long-term  project 
currently  exists  within  the  IGES  Committee  to  develop  PDES.  This  project 
^as  two  primary  objectives: 

1.  to  develop  an  exchange  standard  for  product  data  in  support  of  • 
industrial  automation 

2.  to  represent  the  US  position  in  the  International  Standards 
Organization  (ISO)  arena  relative  to  the  development  of  a  single 
worldwide  standard  for  the  exchange  of  product  data 

A  new  standard  is  being  developed  out  of  the  belief  that  no  existing 
standard  can  be  extended  to  support  industrial  automation  sufficiently 
well. 

"Product  Data"  is  taken  to  be  more  general  than  "product  definition  data". 
It  includes  data  relevant  to  the  entire  life  cycle  of  a  product; 
manufacturing/  quality  assurance#  testing#  sx^pport#  etc.  Development  of  an 
exchange  standard  for  product  data  involves  settling  on  a  set  of  logical 
structures  to  contain  the  product  data  information#  and  also  settling  on 
the  manner  in  wtiich  these  structures  will  be  implemented  in  computer  form. 

The  ISO  Technical  Committee  TC  184  (Industrial  Automation  Systems)  and  its 
Subcommittee  SC4  (External  Representation  Of  Product  Model  Data)  are 
relatively  new  committees  within  ISO#  SC4  having  first  met  in  July#  1984. 
There  is  agreement  within  the  Subcommittee  that  a  single  worldwide  standard 
for  the  exchange  of  product  data  is  needed.  The  goal  of  the  standard  is 
"...the  capture  of  information  comprising  a  computerized  product  model  in  a 
neutral  form... throughout  the  life  cycle  of  the  product".  The  name  of  the 
standard  is  to  be  STEP  -  Standard  for  the  Transfer  and  Exchange  of  Product 
Model  Data. 

The  PDES  Project  has  been  designated  to  tahs  the  leadership  role  in  the 
development  of  STEP.  It  is  the  US  intention  that  PDES  and  STEP  will  be 
identical.  Participating  countries  to  this  date#  besides  the  US#  include; 
France#  Germany#  Japan,  a^itzerland#  and  the  United  Kingdom. 


THE  PDES  RELATIONSHIP  TO  IGES  AND  ITS  DATA  EXCHANGE  HERITAGE 

The  IGES  Steering  Committee  has  outlined  the  relationship  that  is  to  exist 
between  the  IGES  and  the  PDES  specifications.  Work  within  IGES  Technical 
Committees  will  simultaneously  be  directed  toward  future#  upward  compatible 
versions  of  IGES  and  also  toward  a  draft  version  of  PDES.  This  version  of 
PDES  is  to  be#  at  a  minimiin#  fictionally  equivalent  to  the  then-current 
version  of  IGES.  PDES  need  not  be  directly  upwardly  compatible  with  IGES# 
but  must  accommodate  a  conversion  path.  An  IGES  Long  Range  Plan#  now  in 
draft#  will  further  explain  this  relationship  and  other  topics  as  well, 
such  as  test  methodology  and  committee  structure. 

Other  data  exchange  efforts  besides  IGES  will  affect  PDES  in  one  way  or 
another.  In  broad  terms,  the  legacy  of  some  of  these  other  efforts  is  as 
follows:  The  IGES  efforts  form  one  "tier"#  or  logical  grouping#  of 


efforts.  These  have  data  exchange  between  dissimilar  interactive  graphics 
CAD/CAM  systems  as  their  driving  force.  Early  versions  were  implicitly 
targeted  toward  systems  of  the  70 's  and  early  80' s»  and  toward  mechanical 
applications.  Thus/  from  the  start/  2D  drawir^S/  3D  wireframe  models/  and 
certain  generative  type  surfaces  were  emphasized.  With  the  exception  of 
those  entities  expressly  intended  for  the  drawing  application  area  {eg./ 
linear  dimension/  angular  dimension/  general  note/  etc.)/  most  entities 
were  generic  (eg./  line/  arc/  composite  curve/  associativity)/  so  that  the 
intent  of  the  exchanged  data  had  to  be  imposed  from  outside  the  data 
itself.  Typically/  this  would  involve  a  human  viewing  a  representation  of 
the  data  on  a  graphics  system/  keying  off  such  things  as  geometric  shape  or 
placement  relative  to  the  part  itself.  Thus/  the  early  versions  of  IGES 
were  intended  for  hunan  oriented  interpretation  of  the  data  rather  than  for 
automated  interpretation  and  use  of  the  data. 

A  second  tier  of  efforts  consists  of  the  CAM-I  XBF-2  effort/  the  IGES  ESP 
effort/  the  ICAM  PDDI  effort/  and  the  follow-on  CJIAP  effort  sponsored  by 
the  Air  Force  CIM  Program.  (These  acronyms  denote/  respectively/ 
Computer-Aided  tenufacturing-Intemational/  Inc.;  Experimental  Boundary 
File-2;  Initial  Graphics  Exchange  Specification;  Experimental  Solids 
Proposal;  Integrated  Computer  Aided  ffenufacturing;  Product  Definition  Data 
Interface;  Geometric  Modelling  Applications  Interface  Program;  Computer 
Integrated  tenufacturing. ) 

These  efforts  between  them  bring  two  innovations  to  the  fore/  and  in  effect 
usher  in  a  more  modem  product  data  exchange  era.  The  first  innovation  is 
the  emphasis  on  a  more  complete  definition  of  the  shape  of  a  part  -  that 
iS/  the  emphasis  on  solid  modelling/  in  which  the  set  of  spatial  points 
occupied  by  an  object  is  completely  determined.  In  addition  to  this 
complete  "quantitative"  description  of  an  object/  some  systems  also  provide 
a  "qualitative"  description  by  decomposing  the  object  into  topological 
entities  such  as  faces/  edges/  and  vertices  which  describe  the  connectivity 
of  the  part.  These  two  types  of  descriptions  are  then  related  by  having 
the  topological  entities  indicate  which  geometry  entities  are  needed  for 
their  definition. 

The  PDDI  project  went  a  bit  further  than  just  geometry  and  topology 
entities/  identifying  entities  for  other  higher  level  qualitative 
structures  called  part  or  form  "features".  Features  allow  high-level 
concept  comminication  about  parts.  Examples  are  hole/  flange/  thread/  web/ 
pocket/  chamfer/  etc.  The  PDDI  feature  entities  relate  specific  topology 
and  geoi^try  entities  to  a  given  feature  so  that  identifying  information 
for  that  feature  can  be  explicit  in  the  data/  a  necessary  condition  for  the 
support  of  automation.  Geometry/  topology/  and  feature  information  are 
often  collectively  referred  to  as  "shape  information". 

The  other  innovation  from  this  class  of  data  exchange  efforts/  in  fact/ 
from  the  PDDI  and  the  GMAP  efforts/  is  the  emphasis  on  having  the 
comput3rized  part  model  be  a  "complete"  model.  This  means  that  the  model 
contains  all  necessary  shape  and  non-shape  information  sufficient  to 
accomplish  a  given  function;  that  the  information  is  in  a  suitable/  i.e./ 
automation-enabling/  computer  form;  and/  that  the  different  types  of 
information  are  associated  as  required.  For  example/  tolerance  information 
would  be  carried  in  a  form  directly  interpretable  by  a  computer  rather  than 
in  a  computerized  text  form  intended  primarily  for  interpretation  by  a 


human r  and#  this  information  would  be  associated  with  those  entities  in  the 
model  affected  by  the  tolerance.  Other  non-shape  entities  include 
administrative  entities  having  to  do  with  such  things  as  effectivity/ 
specifications f  materials  notes*  etc.  Thus*  the  general  notion  associated 
with  a  complete  part  model  is  that  it  obviates  the  use  of  human-oriented 
drawings  and  other  paper  documents  as  a  necessary  means  of  passing 
information  between  different  functions. 

It  is  interesting  to  note  that  the  first  tier  of  efforts  are  all  standards 
efforts*  concerning  themselves  with  existing  systems  and  techniques*  while 
the  second  tier  of  efforts  are  research  and  development  projects  concerning 
themselves  with  finding  out  how  things  should  be  *  and  ultimately 
intending  to  effect  change. 


THE  CONTENT  EyiPHASIS  OF  PDES 

The  PDES  effort  will  reflect  this  dual  heritage*  and  will  extend  it.  It  is 
intended  that  the  PDES  effort  will  also  have  a  proactive  influence  on  both 
users  and  vendors. 

PDES  will  extend  the  heritage  from  the  stauidards  efforts  and  the  research 
and  development  efforts  by  providing  a  means  for  an  organization  to 
communicate  its  product  breakdown  structure.  This  implies  accommodating 
such  notions  as  part*  subassembly*  assembly*  version*  effectivity*  release* 
etc.*  and  also  accommodating  the  natural  correspondence  between  these  kinds 
of  items  2md  the  configuration  documents*  test  data*  change  directives* 
etc.*  that  pertain  to  these  items.  Many  questions  remain  to  be  answered 
here.  For  example*  a  way  must  be  found  to  relate  the  product  breakdown 
structure  to  the  PC«S  file  or  files  representing  that  product  (as  when  a 
model  has  to  be  spread  over  several  files*  or  several  nx^els  are  contained 
in  one  file)  *  and  to  do  this  in  a  way  that  will  serve  diverse  companies 
that  have  diverse  needs  in  this  area. 


THE  PDES  METHODOLOGY  AND  ITS  CHALLENGES 

The  distinguishing  characteristics  of  the  PDES  methodology  reflect  recent 
developments  in  data  base  and  information  systems  in  general.  They  also 
reflect  techniques  used  and  experience  gained  in  other  data  exchange 
efforts.  The  PDES  methodology  is  significantly  different  from  the  IGES 
methodology. 

The  PDES  methodology  involves:  a  three- layer  architecture  similar  to  the 
three-schema  framework  for  data  base  nanagement  systems  as  identified  by 
AN5I/X3/SPARC;  reference  models;  formal  languages;  and  coordination  with 
other  standards  efforts. 


Three-layer  Architecture 

The  three- layer  architecture  is  similar  to  the  three-schema  framework  in 
which  external*  conceptual*  and  internal  schemas  are  identified.  In  that 
fraunework*  the  conceptual  schema  comprises  the  unique  central  description* 
from  the  standpoint  of  the  enterprise*  of  the  meaning  of  the  data,  and  the 
relationships  among,  and  constraints  upon*  the  data.  It  embodies  the 


"rules  of  the  business".  This  description  is  computer  independent#  i.e.# 
it  is  conceptual,  ,  The  external  schema  represents  the  memner  in  which 
individual  users  and  applications  need  to  view  the  data  represented  by  the 
conceptual  schema.  Each  external  schema  can  therefore  be  supported  by  the 
one  conceptual  schema.  The  internal  schema  represents  the  actual  physical 
computer  storage  structure  being  used  to  store  and  access  the  data.  Within 
PDES#  the  three  layers  corresponding  to  these  three  schemata  are  the 
logical  layer#  the  application  layer#  and  the  physical  layer. 

The  application  layer  will  contain  the  descriptions  and  combinations  of 
information  peculiar  to  various  application  areas.  Information  modelling 
techniques  (or#  data  modelling  techniques#  as  they  may  sometimes  be  called) 
will  be  used  to  formally  expiress  what  the  required  pieces  of  information 
and  their  relationships  are  for  a  given  application  area.  These  models  are 
examples  of  what  are  termed  "reference  models". 

This  layer  will  be  supported  by  application  subgroups  such  as  the  standing 
subcommittees  now  in  IGES:  Advauiced  Geometry#  Electrical#  Mechanical#  AEC# 
FEM,  Drafting#  etc.  The  challenge  here  will  be  to  actually  do  the 
modelling#  then  to  manage  the  networking  of  the  models  into  "clusters" 
depending  on  the  product  under  consideration.  Consistency  and  sufficiency 
wit.iin  each  cluster  must  be  insured.  The  modelling  itself  will  be  a 
challenge  because  the  application  of  information  modelling  techniques  to 
production  artifacts  se^s  to  be  a  new  area. 

The  purpose  of  the  logical  layer  is  to  provide  a  consistent# 
computer-independent  description  of  the  data  constructs  that  will  contain 
the  information  bo  be  exchanged.  Both  generic  and  application-specific 
constructs  are  expected  to  be  identified.  The  central  challenge  here#  and 
perhaps  in  the  entire  PDES  effort#  will  be  to  devise  and  carry  out  a 
conceptualization  and  integration  methodology  by  which  a  minimally 
redundant  set  of  generic  data  structiires  and  relationships  cam  be  produced. 
That  is#  this  set  must  be  as  lean  as  possible#  and  at  the  same  time 
sufficient  to  support  the  wide  range  of  applications.  Some  experience  will 
be  needed  to  be  able  to  settle  on  such  a  methodology,  but  it  will  likely  be 
a  combination  of  a  bottom-up  approach  (i,e,#  abstracting  from  information 
about  individual  application  areas)  and  a  top-down  approach  (i,e,#  deducing 
needed  structures  and  relationships  starting  from  some  global 
classification  schema  for  product  data) ,  Another  challenge  will  be  to 
build  into  the  methodology  the  flexibility  of  being  able  to  consistently 
extend  the  schema  to  accommodate  new  applications.  Establishing  modelling 
technique  requirements  is  also  expected  to  be  challenging. 

The  physical  layer  corresponds  to  the  internal  schema  and  will  be  concerned 
with  the  data  structures  and  data  formats  for  the  exchange  file  itself. 
The  main  challenge  here  will  be  to  establish  and  maintain  efficiency  in 
such  areas  as  file  size  and  processing  time. 

Reference  Models 


A  reference  model  for  some  universe  of  discourse  is  a  model  that  collects 
together  the  necessary  pieces  of  information  and  also  their  relationships 
to  each  other.  The  notion  includes  some  mechanism,  usually  graphical#  for 
describing  the  pieces  of  information  and  the  relationships. 


Reference  models  will  be  used  throughout  the  PDES  architecture.  The 
purpose  is  to  promote  thoroughness  in  domain  analysis  and  precision  in 
definition  and  communication  of  information,  especially  between  different 
layers. 

The  first  challenge  here  for  a  standards  group  that  historically  has  been 
concerned  with  product  data  exchange  issues  is  simply  to  learn  something 
about  reference  models  and  information  modelling,  and  about  the 
requirements  that  any  particular  technique  must  satisfy  in  order  to  be 
useful.  Another  challenge  is  to  effectively  communicate  the  substance  of 
these  issues  to  people  who  are  familiar  with  information  modelling,  but  are 
probably  not  familiar  with  product  data  exchange,  and  to  do  this  in  a  way 
that  results  in  new  talent  being  brought  to  bear  on  our  problems. 

Formal  Languages 

Formal  languages  will  be  used  for  the  definition  of  data  structures  and  for 
the  PDES  file  syntax.  ESnphasis  will  be  on  languages  with  context-free 
grammars  so  that  parsers  can  be  built  more  simply. 

Coordination  With  Other  Standards 


A  final  characteristic  of  the  PDES  methodology  will  be  its  relationship 
with  other  standards  efforts,  both  national  and  international.  How  data  is 
represented  within  PDES,  as  well  as  what  data  is  represented  will  be 
coordinated  with  other  efforts  to  insure  compatability  and  to  minimize 
duplication. 

Experience  from  the  IGES  efforts  has  shown  that  segmentation  of  the 
development  of  a  standard  along  the  lines  of  the  thbee-level  architecture 
woid.d  be  a  desirable  thing.  In  the  IGES  efforts,  there  was  no  explicit 
segmentation.  One  result  was  that,  in  the  course  of  pursuing  new 
application  areas,  application-oriented  people  were  being  held  responsible 
for  things  outside  their  area  of  expertise,  such  as  the  formulation  of 
physical  data  structures.  Another  result  was  that  there  was  no  one 
explicitly  charged  with  maintaining  a  global  viewpoint  toward  the  entity 
set  and  toward  the  consistency  of  the  makeup  of  new  entities.  Thus,  for 
example,  relationships  between  application-specific  entities  and  generic 
entities  may  not  be  consistent  whenever  these  are  used  together.  In  some 
cases  the  application  specific  entity  may  be  subordinate,  while  in  other 
cases  the  generic  entity  may  be  siisordinate.  Almg  the  same  lines,  it  was 
difficult  to  insure  that  the  generic  entity  set  was  kept  as  lean  and 
minimally  redundant  as  possible. 


PDES  VERSION  1.0  -  PROPOSED  CONTENTS 


The  proposed  contents  of  PDES  Version  1.0  as  of  this  time  are  as  follows: 
Application  Layer: 

1.  Mechanical  Products  -  Several  classes  of  parts  modeled,  including  the 
classes  of  machined,  turned,  flat,  and  sheet 

2.  Electrical/Electronic  Products  -  Electrical  Schematics,  Printed  Wiring 
Board  Physical  Design 

3.  Architecture,  Engineering,  and  Construction  (AEC)  -  Heating, 
Ventilating,  Air  Conditioning  (HVAC)  Distribution  Model 

4.  Finite  Element  Modelling  (FEM)  -  Nodes,  Elements,  Loads/Constraints, 
Displacements,  Postprocessing 

5.  Drafting 


Constituent  Technical  Areas 

1.  Manufacturing  Technology  -  Administrative  Data,  Tolerances 

2.  Solid  Modelling  -  Boundary  Representation  (B-Rep.),  Constructive  Solid 
Geometry  (CSG) 

3.  Curve  And  Surface  Modelling  -  Wireframe  Geometi^,  Surface  Geometry 

4.  Presentation  Data  -  Viewing  pipeline.  View  Mechanism,  Text  Definition 

Logical  Layer  -  Develop  conceptualization  and  integration  methodology,  and 
apply  to  application  reference  models 

Physical  Laytr  -  Develop  ASCII  file  format  for  a  single  PDES  file 


PDES  PROOF  OF  CONCEPT  WORK  NOW  UNDER  WAY 

A  PDES  proof >of-concept  and  general  learning  exercise  has  been  under  way 
since  January  of  this  year.  This  work  is  collectively  known  as  the  PDES 
Initiation  effort.  The  effort  will  involve  all  three  layers  of  the 
architecture,  but  is  being  administered  by  two  task  groxqps.  One  is 
associated  with  the  logical  layer,  and  the  other  is  associated  with  the 
physical  layer. 

The  goal  of  the  Initiation  work  for  the  physical  layer  task  group  is  the 
specification  of  a  file  structure  for  the  PDES  exchange  form.  The  current 
draft  of  the  specification  specifies  the  file  stnx:ture  as  being  language 
based,  described  by  an  unambiguous,  context  free  grammar  expressed  in 
Backus-Naur  form.  The  specification  draws  heavily  on  previous  PDDI 
experience  in  this  area. 

The  Initiation  work  for  the  logical  layer  is  divided  into  two  tasks.  The 


goals  of  the  first  task  are  to  illustrate  that  a  conceptual  schema  can  be 
developed  in  support  of  a  specific  application  area,  and  then  to 
communicate  this  schema  to  the  physical  layer  using  a  Data  Specification 
Language  (DSL).  The  Raster  reference  model  for  the  conceptual  schema  will 
Use  the  Nijssen  Information  Analysis  Model  (NIAM)  information  modelling 
technique/  with  the  DSL  description  being  generated  manually  from  this. 

The  goals  of  the  second  task  are  to  illustrate  that  the  initial  conceptual 
schema  can  be  sequent  ally  augmented  in  a  consistent  manner  to  support 
additional  application  reas/  and  then  to  communicate  the  augmented  schema 
to  the  physical  layer  g  oup. 

The  spirit  of  the  initiation  work  is  that  we  will  do  the  best  job  possible 
and  then  will  examine  and  evaluate  the  products  of  our  efforts  and  our 
methodologies.  For  PDES  longer  term  efforts/  what  is  good  will  be  retained 
and  what  is  not  will  be  discarded. 

Many  fundamental  PDES  topics  are  yet  to  be  widely  discussed.  (Examples  are 
requirements  on  pre  and  post  processors  for  effective  implementation  of 
PDES#  requirements  on  user  databases  to  allow  full  advantage  of  PDES/  and 
interplay  between  these.)  The  precise  articulation  and  subsequent 
discussion  of  these  topics  should  be  an  important  part  of  the  longer  term 
PDES  effort. 


THE  PDES  SPECIFICATION  -  SUMMARY 


1.  PDES  is  being  developed  to  support  industrial  automation.  It  will  deal 
with  the  entire  range  of  product  data  and  will  represent  the  US 
position  internationally  in  the  quest  for  a  single  standard. 

2.  PDES  content  will  emphasize  solid  modelling/  complete  product  models/ 
and  product  breakdown  structure.  It  is  intended  that  PDES  will  have  a 
proactive  influence  on  both  users  and  vendors. 

3.  The  PDES  methodology  is  significantly  different  from  the  IGES 
methodology/  and  offers  many  challenges.  It  is  based  upon  a 
three-layer  architecture/  reference  models/  conceptualization  and 
integration/  euid  formal  leuiguages. 

4.  Proof  of  concept  work  is  currently  under  way  and  is  known  as  the  PDES 
Initiation  effort.  Content  and  Rtethodology  beneficial  to  long  remge 
PI£S  work  will  be  kept. 
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The  PDES  Logical  layer  Initiation  Ihsk  Group  is  an  ad  hoc  subconnittee 
of  the  PDES  OoRinittee.  this  leak  Group  mil  perform  work  as  described 
below  as  part  of  the  PDES  Initiation  effort. 

The  purposes  of  the  work  of  this  TSsk  Group  are: 

1.  Examine  the  possibility  and  feasibility  of  developing  PI£S 
according  to  the  three  level  ANSI/X3/SPARC  architecture  as 
suggested  in  the  second  PDES  report. 

2.  Establish  logical  layer  content  «^ich  potentially  could  serve  as  a 
baseline  for  futizre  PDES  development. 

The  two  main  tasks  of  this  Thsk  Group  are: 

1.  Illustrate  that  a  conceptual  schema  can  be  developed  in  support  of 
a  specific  application  area*  and  comminicate  the  structure  of  thin 
schema  to  the  PDES  Physical  File  Strijctures  and  Formal  Languages 
Task  Group. 

2.  Illustrate  that  this  conceptial  schema  can  be  augmented  in  a 
non-redundant  manner  on  an  application-by-application  basis. 

The  first  task  will  contribute  to  illustrating  the  use  of  all  three 
levels  of  the  three  level  architecture.  The  second  task  will 
illustrate  that  the  conceptual  schema  can  be  incrementally  augmented  as 
the  need  arises  -  a  characteristic  of  the  PDES  environment. 

Each  task  will  result  in  a  communication  of  the  conceptual  schema 
content  to  the  Physical  File  Task  Group.  A  Data  Specification  Language 
will  be  used  for  this.  Communication  for  the  first  task  will  be 
approximately  mid-September*  1985*  and  communication  for  the  second 
task  will  be  approximately  November  1*  1985. 

Requests  will  be  made  of  application  groups  to  compose  reference  models 
to  be  used  in  the  second  task.  These  groups  could  conceivably  be  based 
in  existing  IGES  Subcommittees*  or  could  be  ad  hoc. 

A  final  report  will  be  written.  The  report  will  describe  and  docunent 
what  work  was  performed*  and  will  make  recommendations  based  on  this 
experience.  The  general  time  frame  for  this  report  is  January  1*  1986. 

The  Task  Group  will  meet  as  required  in  order  to  accomplish  its  work* 
and  will  periodically  report  on  its  progress. 


T^sk  Overview 


Task  1  A  conceptual  schema  will  be  developed  to  support  the 
mechanical  design  of  flat  plates  tdth  circular  holes.  Wirefrsme 
geometry  will  be  used.  The  schema  will  support  some  uaer>view 
presentation  (viewing)  scenarios  pertinent  to  this  area  of  mechanical 
design. 

The  wireframe  geometry  entities  and  the  presentation  entities  will  be 
devalued  as  part  of  this  task.  A  reference  model  describing  the 
conceptual  schema  will  be  produced.  ^te  Information  Analysis  (lA) 
information  modeling  methodology  will  be  used  for  this  reference  mode.# 
and  the  Data  Specification  langimge  (DSL)  description  of  the  conceptual 
schona  will  be  based  on  this  reference  model. 


Task  2  Four  Application  Thsk  Groi^Ds  will  be  contacted  to  compose 
reference  models.  These  models  will  be  used  one  at  a  time  to 
cunulatively  aLtgment  the  conceptual  schema  produced  in  the  first  task. 
A  reference  model  depicting  the  "final"  conceptual  schema  will  be 
produced#  as  will  a  mapping  illustrating  how  each  application  makes  use 
of  the  conceptual  schema.  The  cumulative  augmentation  of  the 
conceptual  schema  will  involve  integration  in  the  sense  that  a  minimun 
nunber  of  "generic"  entities  and  structures  will  be  sought  to  support 
the  ojmmon  needs  of  the  various  applications. 

The  integration  work  is  the  focal  point  of  this  task.  The  Information 
Analysis  (lA)  modeling  methodology#  and  associated  Software  Tools  (ST)# 
will  be  used  to  support  this  work.  (Specifically#  lAST#  a  CDC  software 
product  in  the  possession  of  those  who  will  be  doing  the  integration 
work#  will  be  used.)  In  order  to  provide  a  common  footing  for  the 
integration  work#  and  to  make  possible  the  use  of  the  supporting 
software#  each  reference  model  from  an  Application  Task  Group  will  be 
translated  into  an  equivalent  lA-based  reference  model #  and  entered 
into  lAST.  The  resulting  translated  reference  model  will  be 
scrutinized  from  a  "Quality  Assurance"  point  of  view.  A  liason  from 
the  referring  Application  Task  Group  will  assist  in  understanding  and 
possibly  refining  the  reference  model#  thereby  closing  the  QA  loop. 

I A  will  be  used  to  describe  the  final  conceptual  schema#  and  also  to 
illustrate  how  each  application  makes  use  of  the  conceptual  schema.  As 
in  the  first  task#  the  Data  Specification  language  description  of  the 
conceptual  schema  will  be  based  on  the  lA  reference  model  of  the 
conceptual  schema. 


The  Application  Reference  Models  Are: 

1.  Mechanical  Design  -  Flat  Plates  With  Circular  Holes 

2.  Electrical  Design  >  Schematics 

3.  Ttolerancing  -  Tolerances  In  Y14.5M  And  ISO  1101  and  1660 

4.  Finite  Element  -  Finite  Element  Environment 

5.  AEC  -  AEC/HVAC 

Recommendations  For  General  FDES  Evaliations#  recommendations#  and 
experiences  based  on  this  vfork  will  inclx:de: 

1.  ^  evaluation  of  the  three  level  architecture  as  an  environment  for 
developing  POES. 

2.  Recommendations  for  a  logical  layer  integration  methodology. 

3.  Recommendations  for  application  layer  information  modeling 
techniques. 

4.  Experiences  with  the  use  of  automated  tools. 


Pigs  Logical  Layer  Initiation  Task  Group 


Z.  Bodnar#  CDC 

D.  Briggs#  Boeing 

R.  Brown#  Hxjghes  (New  Member) 

E.  Clapp#  IBM#  Wireframe  Geometry  Leader 

S.  OePauw#  caterpillar#  Plat  Plate  Design  Task  Leader 
R.  (^le#  DkOCr: 

D.  Hemmelgam#  ITT 

J.  C.  Kelly#  Sandia#  Chairman 

P.  Kennicott#  GE 

H.  Ladd#  DuPont  (New  Member) 

D.  Schenck#  HcDonnell'Douglas#  DSL  Task  Leader 
D.  Theilen#  Allied/Bendix#  Logical  Layer  Integration  Task  Leader 
D.  Winfrey#  DEC#  Presentation  Task  Leader 
J.  Zimmerman#  Allied/Bendix 


Application  Layer  Tasks  Initiated  By  Request  Of  The  Logical  ^yer 
Initiation  Task  Group  And  Their  Coordinators  With  Ttie  Logical  Layer 

1.  Mechanical  Design  »  Reference  Model  Fbr  Flat  Plates 

S.  dePauw  -  Caterpillar#  Task  Leader 
D.  Hemmelgam  -  ITI 

2.  Electrical  Design  -  Reference  Model  Fbr  Schematics 

C.  Parks  -  General  Dynamics#  Task  Leader 

P ,  •  Kennicott  -  General  Electric 

Work  Supported  By:  IGES  Electrical  Subcommittee 

3.  Tblerancing  -  Reference  Model  Fbr  Tblerances  In  Y14.5M 

R.  Colsher  >  IGES  Data  Analysis#  Task  Leader 
B.  Burkett  -  McOonnell-Douglas 

Work  Supported  By:  IGES  Drafting  Information  Model  WG 

4.  Finite  Element  -  Reference  Model  For  FE  Ebvirorroent 

R.  Ivey  -  Westinghouse#  Task  Leader 

B.  Freeman  -  Allied/Bendix 

Work  Supported  By:  IGES  FEM  Subcommittee 

5.  AEC  -  Reference  Model  Fbr  AEC/HVAC 

F.  Stahl#  IBM#  Task  Leader 
P.  Rourke#  Newport  News  Shipbuilding 

J.  Turner#  University  Of  Michigan 
Work  Supported  By:  IGES  AEC  Subcommittee 
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_  Memorandum 

Bendix 
Aerospace 

Date:  March  5,  1985 

To:  Roger  W.  Gale,  Chairman,  PDES  Reference  Model  Selection 

From:  J.  J.  Zimmerman,  PDES  Physical  Layer  Committee  Member 

Subject:  SUMMARY  OF  NIAM  MODELING  METHOD 


Bendix  Kansas  City  Division 
Kansas  City,  Missouri 


LLIED 


I  understand  the  critical  nature  of  selecting  an  adequate 
reference  model  for  the  BDES  logical  layer.  In  response  to 
your  call  for  alternatives  to  IDEF,,  I  present  this  NIAM 
overview.  ^ 

NIAM  (Nijs sen's  Information  Analysis  Method)'  is  a  binary  data 
modeling  method  developed  in  Europe  by  Dr.  G.  M.  Nijs  sen  in 
1972.  The  method  as  it  is  used  today  is  nearly  the  same  as 
the  1975  version  with  some  dialectical  changes.  It  has  been 
applied  to  application  projects  in  Europe  since  1975  and  is 
well  recognized  and  respected  there.  It  has  been  used  in  the 
states,  however,  only  since  about  1980  and  now  several  major 
U.S.  corporations  are  using  NIAM.  Since  1984,  Qint  Database 
Systems  Corporation  has  supported  NIAM  with  QINT/IAM  and 
QINT/TINA  support  tools.  Since  1980,  Control  Data 
Corporation  has  supported  NIAM  with  IAS  (Information  Analysis 
Support)  which  consists  of  education,  consulting,  project  • 
management  services,  and  support  software. 

The  method  itself,  its  nomenclature,  and  graphical  language 
are  public  domain  and  are  well  described  by  ISO  working  group 
ISO/TC97/SC5/WG3  in  report  SC5-N695.  I  understand  this 
working  group  is  now  ISO/TC97/SC21/WG5-3  and  the  original 
report  has  been  republished  as  report  SC21-N197. 

This  working  group  was  formed  to  bring  some  formality  to  the 
ANSI/X3/SPARC  three  schema  DBMS  architecture — particularly 
the  conceptual  schema.  As  you  will  notice  in  the  report,  the 
working  group  used  NIAM  as  a  representative  for  a  broad 
category  of  models  called  binary  models.  The  other  categories 
were  EAR  (Entity  Attribute  Relationship — which  I  think  is  the 
category  IDEF,  belongs  to)  and  IPL  (Interpreted  Predicate 
Logic) .  The  fact  that  ISO  chose  NIAM  as  a  representative  for 
binary  modeling  indicates  European  recognition.  I  am  sending 
you  a  copy  of  ISO  report  SC5-N695.  You  will  find  a  pretty 
thorough  comparison  of  the  EAR  and  binary  approaches  which  I 
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think  represents  a  fair  theoretical  comparison  of  IDEF,  and 
NIAM.  ^ 

The  following  are  the  major  strengths  of  NIAM: 

o  It  has  international  acceptance. 

o  The  method  is  in  public  domain. 

o  .  There  is  a  body  of  people  with  experience  with  the 
methodology  in  Europe  and  North  America. 

o  End  users  find  it  easy  to  learn. 

o  The  method  has  a  rigorous  basis  in  classical  linguistic 

and  mathematical  theory.  This  rigorous  basis  is  the 
foundation  for  a  formal  language  description  for  NIAM. 

This  formal  language  is  computer  sensible. 

o  NIAM  clearly  separates  the  process  of  problem  space 

semantic  analysis  from  the  design  of  logical  and  physical 
record  structures. 

o  Computerized  tools  are  commercially  available  to  support 
model  creation,  model  access,  and  model  conversion  to 
logical  record  structures  and  physical  file  formats. 

Both  NiAM  and  IDEF,  methods  are  striving  for  the  same  goal-- 
the  rationalization  of  information  in  preparation  for  integrated 
system  development.  More  specifically,  in  Appendix  A  I  have 
siammarized  areas  in  which  NIAM  is  superior  to  IDEF^^  as  you 
requested  in  your  letter. 

In  general,  I  believe  NIAM  is  superior  to  IDEF,  as  a  concep¬ 
tual  data  modeling  reference  language  for  PDES'*' logical  layer 
development . 
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We  are  prepared  to  bring  more  information  to  you  in  greater 
detail.  Thank  you  for  you  attention. 

Address  correspondence  to: 

John  J.  Zimmerman,  MH39 
Allied  Bendix  Aerospace 
P.  0.  Box  1159 
Kansas  City,  MO  64141 
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Attachment 


APPENDIX  A 


Features  provided  by  NIAM  that  are  not  provided  by  IDEF^^ . 

1)  NIAM  is  an  internationally  recognized  and  respected  modeling 
method.  It  is  used  by  major  corporations  in  North  America 
and  Western  Europe.  Its  formal  basis  in  linguistics  and  set 
theory  are  well  recognized. 

Why  the  difference  is  important; 

PDES  logical  schemas  must  be  communicated  internationally. 
International  recognition  of  the  modeling  language  will  be  a 
critical  factor  in  ISO  negotiations. 

2)  NIAM  is  a  binary  entity-relationship  modeling  technique  that 
clearly  separates  the  process  of  determining  meaning  of 
entities  and  their  relationships  from  the  process  of  designing 
logical  data  records  (the  process  of  determing  key 
structures,  normalization,  and  inter-record  linkages). 

Why  the  difference  is  important; 

The  information  analyst  should  be  dedicated  to  the  task  of 
understanding  the  meaning  and  relationships  of  the  entities. 
The  thought  process  should  not  be  split  between  semantic 
analysis  and  logical  record  design.  Increased  concentration 
on  the  meaning  of  the  problem  space  is  the  most  significant 
benefit  to  logical  data  modeling. 

3)  IAS  software  provides  for  the  automatic  conversion  of  the 
NIAM  binary  model  representation  to  normalized  logical 
record  structures. 

Why  the  difference  is  important; 

Reduces  human  labor  and  human  error. 

4)  IAS  software  provides  for  the  automatic  conversion  of  the 
NIAM  binary  model  representation  to  target  physical  data 
representations.  These  converters  are  called  "PIPES." 

Several  DBMs  pipes  are  already  in  existence. 

Why  the  difference  is  important; 

A.  This  capability  allows  the  conceptual  schema  to  stand 
alone,  independent  of  any  physical  data  representation. 

It  allows  for  multiple  expeiimental  or  optional  physical 
file  formats  to  exist.  I  believe  there  is  significant 
potential  to  pipe  NIAM  constructs  from  the  NIAM  concep¬ 
tual  schema  to  the  PDES  physical  transfer  file  format 
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without  any  other  intervening  formal  conceptual 
languages . 

B.  The  minimization  of  the  number  of  conceptual  languages 
used  in  building  the  FDES  logical  model  should  enhance 
efficiency  of  communication  and  reduce  learning  overhead 
for  logical  modelers. 

5)  The  NIAM  graphical  language  contains  a  rich  set  of  inter¬ 
entity  constraint  constructs. 

Why  difference  is  important; 

Explicit  constraint  representation  in  the  model  reduces  the 
amount  of  narrative  associated  with  the  conceptual  schema 
and  provides  improved  communications  by  using  a  standard 
constraint  notation.  The  end  result  is  a  conceptual  schema 
that  is  richer  in  meaning  without  introducing  interpretation 
error . 

6)  NIAM.  separates  functional  dependency  notation  from  existence 
dependency  notation.  This  modularity  allows  the  analyst  to 
use  all  16  combinations  of  functional  dependency  (4)  and 
existence  dependency  notation  (4). 

Why  difference  is  important; 

It  allows  the  analyst  to  be  more  expressive  by  using  any 
combination  of  functional  and  existence  dependency.  The 
analyst  does  not  need  to  add  extensions  to  the  modeling 
language . 

7)  The  NIAM  model  uses  a  simple  set  of  rigorously  defined  model 
constructs  that  have  fotindations  in  classical  linguistics. 

The  four  most  significant  constructs  are  LOT  (lexical  object 
type--classes  of  object  representations),  NOLOT  (nonlexical 
object  type--classes  of  objects),  IDEA  (relationship  between 
two  nonlexical  objects)  and  BRIDGE  (relationship  between  a 
LOT  and  a  NOLOT) . 

Why  difference  is  important; 

A.  These  constructs  form  the  basis  for  a  simple  but 
rigorous  modeling  language  that  is  computer  sensible. 

A  computer  sensible  language  provides  capability  for 
computer  assisted  access  to  complex  model  structures. 

B.  These  constructs  improve  the  analyst's  ability  to 
understand  and  denote  the  difference  between  an  object 
and  the  object's  name. 
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C.  Gives  analyst  the  ability  to  rigorously  denote  synonyms, 
abbreviations ,  homonyms ,  and  arbitrary  lexical  mappings . 

8)  IAS  software  provides  the  automated  capability  to  integrate 
complex  functional  area  model  views  by  resolving  different 
functional  area  or  problem  specific  naming  conventions  with 
synonym  tables. 

Why  the  difference  is  important; 

Resolving  naming  differences  within  various  PDES  application 
reference  models  is  a  mandatory  step  in  the  process  of  model 
integration  at  the  conceptual  layer.  Synonym  capability 
also  allows  the  conceptual  modeler  to  use  abstract  naming 
conventions  that  will  promote  integration.  This  capability 
will  allow  separate  groups  to  work  independently  and  yet 
have  their  model  intersections  reconciled. 

9)  IAS  software  provides  a  set  of  automated  cross  reference 
tools  that  serve  functions  similar  to  Entity  Class/Attribute 
Class  Matrix,  Class  Migration  Index,  Attribute  Class  Migration 
Class  Index,  and  Relation  Matrix. 

Why  the  difference  is  important; 

Building  these  kinds  of  cross  reference  tables  manually  as 
in' IDEE,  is  extremely  labor  intensive  and  error  prone. 
Analyst'^'resistance  to  model  changes  will  grow  as  manually 
derived  tables  become  more  complex  and  interweaved.  The 
analyst  should  not  be  required  to  mantially  build  model 
indices  that  can  be  built  automatically. 

10)  NIAM  allows  for,  but  does  not  demand,  refinement  of  relation¬ 
ships  in  which  existence  independence  exists  on  both  ends. 

Why  the  difference  is  important; 

It  is  understandable  that  the  most  stable  information 
structure  is  desirable  in  the  end  result.  It  is  unreasonable 
for  the  modeling  language  to  dictate  that  all  relationships 
be  refined.  The  demand  for  mandatory  refinement  can  often 
be  arbitrary  and  place  an  \mnecessary  burden  on  the  analyst. 
The  modeling  of  physical  artifacts  in  PDES  will  involve 
naturally  occurring  many-to-many  relationships  which  have 
legitimate  existence.  Refinement  is  artificial  except  when 
an  relationship  is  better  thought  of  as  an  object  (in  the 
case  when  the  relationship  itself  is  associated  with  many 
entities) . 


3 


Appendix  H 


Summary  of  Responses  to  Call  for  Alternative  Modeling  Lancmages 


42 


TO:  PDES  Committees  and  Working  Groups 

FROM:  Roger  W,  Gale  —  Logical  Layer  Reference  Model 
Selection 

SUBJECT:  Comparison  of  Proposed  Modeling  Methods  and 
Recommendations  for  Selection 

Dan  Appleton  is  fond  of  saying,  "the  methods  used  have  more  to  do 
with  the  outcome  than  the  objectives".  My  experience  leads  me  to 
agree  with  him.  I  believe  that  we  should  be  concerned  not  only 
with  the  elegance  of  a  selected  model  for  the  logical  layer  but 
with  the  method  used  to  arrive  at  the  model  as  well. 
Accordingly,  I  am  biased  toward  how  we  are  to  arrive  at  the  model 
somewhat  more  than  toward  a  resulting  model  which  has  one  or  two 
more  bells  or  whistles. 

There  are  only  two  models  which  have  been  given  support  as 
candidates  for  the  PDES  Logical  layer  reference  model.  The  ICAM 
IDEFl  model  received  four  recommendations  and  the  ISO  TC97/SC5  - 
N  695  received  one. 

There  are  differences  in  the  methods  behind  the  two  models  which, 
I  believe,  affect  their  utility  for  the  purposes  of  PDES.  The 
most  significant  difference  is  that,  in  essence,  IDEFl  is  a 
"top-down"  method  while  the  ISO  is  a  "bottom-up"  method. 

The  advantages  I  see  in  the  IDEFl  method  are  that  it  is 
"top-down"  and  is  more  "people  friendly".  The  "people  friendly" 
aspect  is  important.  The  ICAM  experience  seems  to  have 
demonstrated  that  the  IDEFl  method  assists  people  to  arrive  at  a 
conceptual  model  of  the  enterprise  data.  That  model  is  of  the 
conceptual  data  view  of  the  business  we  are  in.  It  is  not  a 
model  of  computer  systems,  but  rather,  a  definition  of 
requirements  for  data  integrity  which  must  be  met  when  computer 
systems  are  implemented.  It  is  not  easy  for  people  who  have  been 
trained  in  classic,  two-schema,  computer  systems  development 
methods  to  learn  to  think  in  terms  of  the  third  schema,  the 
conceptual  enterprise  model,  rather  than  the  bits,  bytes, 
records,  fields,  etc.  of  computer  implementation.  We  need  all 
the  help  we  caji  get  because,  in  the  end,  it  is  the  people  who 
must  do  it. 

In  addition,  the  PDES  logical  layer  model  is  ultimately  a  part  of 
a  larger  enterprise  model  on  which  work  already  is  underway  in 
many  firms.  Much  of  that  enterprise  modeling  is  already  in  the 
IDEFl  method  (for  example,  the  ICAM,  MFGl  model). 
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The  disadvantage  of  IDEFl  may  lie  in  the  lack  of  a  standard, 
structured  definition  language  for  text  description  of  the  model 
and  those  needed  data  constraints  not  shown  in  the  graphics. 
This  disadvantage  may  tend  to  go  away  if  one  of  th^  software 
tools  for  IDEFl  models  is  used  because  some  of  those  tools,  such 
as  the  one  from  the  Dan  Appleton  Co.  use  a  structured  modeling 
language  to  define  the  model  which  has  similarities  to  Lhe 
definition  language  found  in  the  ISO  Standard. 

I  have  received  from  J.  C.  Kelly,  "A  Preliminary  PDES  Logical 
Layer  Document"  dated  March  13  1985.  Attachment  G  of  that 
document  is  by  Douglas  Schenk.  In  it  is  a  proposed  specification 
language  for  the  PDFS  Logical  Layer  which  would  describe  a 
different  model  from  the  IDEFl  model.  The  concept  of  a 
structured  model  description  language  is  well  represented  in  his 
paper. 

The  methodology  behind  the  ISO  model  is  available  with  automation 
from  Control  Data.  I  think  it  can  be  summarized  as  an  approach 
in  which  "attributes"  are  related  to  each  other  and  the  data 
structure  is  determined  from  the  binary  relationships.  The  model 
provides  a  graphic  representation  which  is  supported  by  a  very 
specific,  structured  model  language  in  which  data  constraints  are 
defined . 

An  advantage  of  the  ISO  model  is  that  the  very  structured  model 
definition  language  is  very  attractive  to  computer  system 
implementors.  A  disadvantage  is  that  the  graphics  convey  only  a 
limited  portion  of  the  model  and  the  language  statements  must  be 
studied  to  find  most  of  the  data  constraints.  My  personal 
reaction  is  that  it  is  difficult  to  grasp  the  model  because  it  is 
hard  to  see  the  data  context  in  the  business  sense  which  should 
be  a  primary  objective  of  the  model. 

The  methodology  behind  the  IDEFl  model  is  one  of;  identifying 
objects  of  interest  (entities)  about  which  the  enterprise 
maintains  data,  determining  how  the  enterprise  relates  those 
entities,  identifying  the  attributes  of  the  entities  and  then 
refining  the  model  according  to  some  simple  rules  to  arrive  at  a 
normalized,  relational  model. 

•Software  is  available  from  several  sources  providing  more  or  less 
assistance  with  developing  the  IDEFl  models.  AUTOIDEF  is 
basically  a  computer  aided  drafting  tool  for  models  developed 
under  ICAM.  Other  software  may  be  purchased  from  its  developers. 
Some  of  the  software  provides  extensions  beyond  the  basic  IDEFl 
which  produce  graphic  illustration  of  additional  data 
constraints. 
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Action  is  underway  now  to  produce  a  new  version  of  IDEFl  which 
will  contain  additional  model  conventions  to  illustrate  data 
constraints.  One  effect  of  the  new  version  will  be  to  reduce  the 
difference  between  the  two  methods  in  terms  of  the  degree  of  data 
constraint  definition. 

According  to  Dave  Theilen,  John  Zimmerman  with  him  at  Bendix,  is 
of  the  opinion  that  he  will  not  find  it  difficult  to  translate 
from  one  model  form  to  the  other  in  either  direction.  John  has 
considerable  experience  with  the  Control  Data  modeling  software 
and  some  experience  with  the  IDEFl  model.  It  is  Dave  Theilen' s 
intent  to  perform  those  translations  in  the  course  of  integrating 
the  various  PDES  application  models  into  the  logical  layer.  If 
that  proves  successful,  we  may  be  able  to  take  advantage  of 
desirable  features  of  both  methods. 

Based  upon  my  understanding  of  the  differences  and  utility  of  the 
two  methodologies,  and  the  expressions  of  support  from  the  IGES 
community,  I  recommend  the  following: 

1.  Adopt  the  IDEFl  modeling  methodology  for  the  PDES 
logical  layer  (utilizing  new  versions  as  they  become 
available ) . 

2.  Pursue  the  possiblity  of  translating  the  IDEFl  model 
into  an  ISO  model  and,  if  found  feasible,  make  that  a 
practice  for  PDES. 

3.  Ask  Douglas  Schenk  to  revise  his  specification  language 
so  that  it  is  a  description  of  an  IDEFl  model  plus  those 
additional  data  constraints  considered  necessary  but  not 
contained  in  the  IDEFl. 

4.  Develop  written  additions  to  the  documentation  of  the 
IDEFl  methodology  to  describe  the  methods  to  be  used  to 
arrive  at  the  definition  of  those  additional  data 
constraints  found  necessary  for  item  3.  above. 

It  appears  to  me  that  there  is  some  confusion  regarding  the  roles 
and  contents  of  each  of  the  three  schemas  identified  by  ANSI 
SPARC  which  are  the  three  layers  proposed  for  PDES.  It  is  going 
to  be  difficult  to  go  forward  with  a  three-schema  idea  if 
everyone  has  a  different  idea  if  what  is  in  each  schema.  There 
is  a  need  for  people  working  on  a  schema  to  understand  what  it  is 
and  what  it  is  not. 
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It  should  be  understood  that  the  IDEFl  method  is  for  modeling  the 
Logical  Layer  (conceptual  schema),  or  portions  of  it.  There 
appears  to  be  some  confusion  about  the  use  of  this  modeling 
method  to  model  applications.  Applications  are  in  the  realm  of 
the  ANSI  SPARC  external  schema  or  user  views.  IDE^l  is  for 
modeling  data.  External  schemas  contain  information  as  well  as 
data.  Information  is  derived  from  data  through  some  sort  of 
algorithm.  For  example,  a  persons  age  is  information  derived 
from  current  date  and  the  persons  date  of  birth.  The  IDEFl  model 
can  contain  "current  date"  and  "persons  birth  date"  but  not 
"age" . 

The  task  of  each  application  sub  committee  should  be  to  examine 
their  application  and  produce  an  IDEFl  model  which  identifies 
that  set  of  entities,  attributes  and  relationships  of  the  logical 
layer  (Conceptual  Schema)  which  are  necessary  for  the 
application.  This  might  be  more  easily  understood  as  a 
sub-schema  of  the  logical  layer. 

I  have  not  found  much  work  relating  to  methods  for  modeling,  or 
describing,  a  "user  view"  or  external  schema  which  are,  I 
believe,  other  names  for  an  application. 

The  choice  of  description  of  the  physical  layer  (or  internal 
schema)  is  dictated  by  the  choice  of  implementation.  The 
description  of  a  CODAS  YL  .data  base  ..d  if  fees,  fcom  tha.t  of  a 
relational  database  which  is  different  from  that  of  a 
hierarchical  database. 


Rog^r  W.  Gale 
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Appendix  I 

Letters  on  Critical  Issues 
Written  Purina  Initiation  Effort 
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PRODUCT  DEFIHITION  DATA  SCOPE 


The  PO  in  PDES  stands  for  Product  Definition,  it  is  easy  to  spedc  freely  of  POES  but  it  is 
difficult  to  establish  just  what  is  Product  Definition.  In  this  paper  I  will  offer  a  few  thoughts 
about  what  sorts  of  data  might  be  within  the  scope  of  Product  Definition. 

For  the  moment,  let  us  consider  four  classes  of  data.  The  first  I  will  name  Product  Data.  This  is 
data  about  tha  objects  to  be  manufactured.  Product  Data  is  mostly  setting  requirements  stated  in 
terms  of  functional  and  physical  characteristics  which  should  be  present  in  the  objects  when 
they  have  been  manufacture!  it  includes  text  and  geometry  data  as  well  as  alpha-numeric  data. 
The  second  I  will  call  Production  Data.  Closely  related  to  Product  Data,  this  data  describes  how 
the  objects  are  to  be  manufactured  The  third  1  will  call  Operational  Data  This  data  is  closely 
related  to  Production  Data  but  describes  the  events  of  production,  such  as  lot  size,  schedule, 
sequence  of  assembly,  etc.  The  fourth  class  I  will  call  Rasourta  Data  This  data  is  closely 
related  to  Operational  Data,  but  it  describes  the  resources  that  are  involved  in  operations,  c.g. , 
machines,  people  and  money. 

ProAjct  Definition  Data  probably  includes  all  Product  Data,  most  Production  Data,  some 
Operational  Data  and  little  or  no  Resource  Data 

Now  let  us  think  about  a  method  for  documenting  the  Product  Definition  Data  Scope  and 
establishing  its  content 

For  years  we  have  considered  the  use  of  computers  from  the  standpoint  of  automating  particular 
processes.  Planning  methodologies  were  based  upon  establishing  the  relationship  of  data  to 
processes.  There  is  already  an  activity  ^ing  on  related  to  STEP  wherein  a  very  complicate 
matrix  is  being  developed  essentially  relating  processes  to  data  modified  by  life  cycle  stages. 

Now  that  we  have  data  management  technologies  such  as  data  base  managment  systems,  we  can 
realize  that  data  is  a  shareable  asset  which  can  be  considered  on  its  own  merits.  This  is  as  true 
of  the  data  which  describes  product  as  it  is  of  any  other  data  within  an  enterprise.  I  suggest  that 
we  should  consider  the  Product  Definition  scope  as  a  data  scope.  In  the  Data  Scope  we  become 
interested  in  how  data  are  related  to  data 

The  tool  for  describing  a  data  scope  is  the  same  tool  that  we  can  use  to  define  the  Logical  Layer  of 
PDES.  That  is  a  logical  data  model.  The  data  model  which,  with  its  companion  method,  has 
already  been  most  widely  used  for  Cin  data  in  this  country  is  IDEF1.  There  is  an  extended 
vsrsion  of  the  model  now  in  work  which  provides  improved  definition  of  data  rules  and 
constraints.  However,  when  we  are  constructing  a  Data  Planning  riodel  we  do  not  need  to 
identify  all  of  the  attributes  of  entities  and  fully  normalize  the  model.  It  should  be  enough  to 
resolve  non-specific  relationships  and  establish  the  Key  attributes  of  the  Entities.  We  call  this 
a  Key-Based  model.  The  examples  I  use  will  be  in  the  D.  Appleton  Co.  Data  nodeling  Technique 
which  is  essentielly  the  same  as  the  extended  IDEF I . 
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If  we  begin  with  the  design  of  a  product  we  find  that,  until  the  advent  of  computers,  the  product 
'as-dasigned'  exists  as  a  set  of  documents  which  completely  describe  the  functional  and  physical 
charactaristics  of  the  product  and  each  of  its  subdivisions.  For  the  subdivisions  we  have  used  a 
lot  of  terms  such  as  assembly,  subassembly,  part  and  material.  I  will  use  the  single  term 
"Item"  to  include  all  of  these. 

Let  us  begin  with  some  simple  definitions  and  business  rules; 

I.  An  Item  may  contain  other  Items  as  components. 

Z  An  Item  may  be  a  component  of  other  Items. 

3.  A  document  which  contains  all  or  part  of  the  characteristics  of  an  Item  is  a  Configuration 
Document 

4.  A  Confl^iration  Document  may  invoke  other  Configuration  Documents  to  establish  item 
characteristics. 

5.  A  Configuration  Document  may  be  invoked  by  other  Configuration  Documents. 

6.  Every  Configuration  Document  has  at  least  one  Revision,  the  original,  and  mev  have 
subsequent  Revisions. 

Different  Revisions  of  a  Configuration  Document  ma/  invoke  different  Configuretion 
Documents. 

8.  Any  Revision  to  a  Configuration  Document  for  an  Item  results  in  a  Version  of  the  Item. 

9.  Every  I  tern  has  at  least  one  Version .  the  or  iginal ,  and  ma/  have  subsequent  Versions. 

1 0.  Different  Versions  of  an  Item  may  have  different  Components. 

II.  A  Configuration  Document  defines  chw^eristics  for  one  or  more  Items. 


From  these  rules  we  con  construct  the  data  model  of  Figure  1 .  i  believe  that  this  is  the  most 
pivotal  portion  of  the  Product  Definition  data  model.  All  of  the  early  efforts  to  establish  the 
requirements  which  the  design  must  satisfy  i^ive  toward  the  "as-designed"  product  In  turn,  it 
(t'ives  the  subsequent  manufacturing  actions  which  first  establish  the  "as-planned" 
configuration  and  finally  result  in  an  "as-built"  configuration. 
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FICUBD 

I  believe  Ihet  a  primary  hurdle  confronting  CIM  is  to  succesafully  capture  the  ■as-designed" 
product  definition  and  transfer  it  in  e  manner  that  allows  automated  generation  of  the 
"as-planned"  configuration. 

We  have  started  to  capture  some  of  the  Product  Definition  in  CAD  systems  and  lOES  was  an  early 
effxt  to  aid  automated  transfx  of  data  from  theCAO  systems.  However,  the  data  in  todey'sCAD 
systems  is  fx  from  a  complete  Product  Definition.  Furthermore,  the  data  which  are  present 
usually  require  a  human  in  the  loop  fx  intxpratatix.  Fx  example,  tolxances  have  usually 
been  expressed  in  such  a  way  that  we  cannot  make  a  computx  program  interpret  them  to 
automatically  control  the  output  of  an  NO  machine. 

Let  me  suggest  here  that  Configuretix  Documents  may  come  in  a  vxiety  of  media  which  can 
include  digital  data  I  think  that  a  CAD  system  file  may  be  one  of  those  documxts  in  the  data 
model  of  Figure  1. 

So  fx,  I  believe  that  the  focus  of  lOES  and  of  PDES  has  been  on  the  very  difficult  task  of 
understanding  and  defining  the  date  by  which  we  desxibe  the  shape  of  Items.  In  Figure  1  we 
have  a  data  model  which  will  provide  a  context  into  which  we  may  fit  the  shape-defining  data 
models  x  which  we  have  concentrated. 

« 

Anothx  key  element  of  Product  Dcfinitix  is  the  directive  that  specific  vxsions  of 
‘as-designed"  items  should  appex  in  specific  units  of  delivxed  product.  This  is  genxally 
known  as  Effectivity.  Effectivity  usually  is  assigied  at  the  time  of  Release.  Release,  in  concept, 
seems  to  be  establishing  a  status  for  a  cxfiguratix  of  on  Itam  which  pxmits,  x  directs, 
mxufacture  of  the  Item. 
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There  seems  to  be  a  popular  opinion  that  what  we  release  is  Documents.  A  good  friend  of  mine  in 
the  Configuration  Management  business  suggests  that  what  we  really  ou^t  to  be  releasing  is 
Item  Versions.  In  Figure  2, 1  have  modeled  the  release  of  Item  Configuration  Documents  which 
seems  to  be  an  attempt  to  do  both.  However,  this  model  would  only  release  Configuration 
Documents  to  the  degra  that  they  define  specific  Items.  Items  defined  on  the  Configuration 
Documents  which  heve  no  product  usage  are  not  released. 
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Now  let  me  Wee  this  Product  Definltiwi  deta  model  a  step  or  two  further.  Jt  is  common  for  the 
people  planning  the  manufacture  of  something  which  engineering  has  designed  to  find  that  the/ 
cannot  manufacture  items  in  exactly  the  manner  in  which  they  are  described  in  the  design.  For 
example,  the  designer  of  a  multi-layer  printed  circuit  board  treats  the  board  as  a  single  item 
for  which  he  describes  the  circuit  paths  to  appear  on  each  of  the  le/ers.  The  manufacturing 
folks  have  to  take  the  multiple  layers  apart  and  make  several  items,  each  with  le/ers  of  circuit 
on  each  side,  and  then  bond  them  together  to  arrive  at  the  item  the  design  engineer  described. 
Thus,  manufacturing  hes  several  items  where  the  designer  had  one.  These  'phantom*  or 
'synthetic'  items  appear  in  the  'as-planned*  product  structure  for  manufacturing  and  cause  it 
to  contain  items  not  identified  as  items  in  the  'as-designed*  product  structure. 

The  result  of  the  planning  process  is  that  there  is  an  'as- planned*  set  of  Items  and  Configuration 
Documents  which  hes  a  data  model  structure  like  thet  of  the  *as-designed*  but  is,  fact  a  different 
structure  with  some  differing  content  The  Configuration  Documents  for  these  Items  are 
documents  created  in  the  manufacturing  planning  process;  operation  and  routing  sheets  is  one 
term  far  such  documents.  These  document  usually  will  refer  to  the  *es-dBsigned' 
Configuration  Documents  to  establish  the  configuration  chain.  The  Entities  and  Attributes  of  this 
structure  must  be  given  unique  names  and  definitions.  The  logical  relationship  of  the 
*as-dBsignad*  and  'as-planned*  structures  needs  to  be  established.  Figure  3  suggests  a  possible 
logical  relationship. 

During  the  design  process,  we  typically  evaluate  the  functionality  of  the  Items  by  modeling  or 
simulating  the  p^ormance  of  the  item  based  on  the  characteristics  established  in  the 
Configuration  Documents.  This  is  the  design  process  equivalent  of  the  performance  of  tests  on 
actual  product  units  once  fabricated.  The  evaluations  and  their  resulb  should  be  related  to  the 
specific  versions  of  the  Items  to  which  they  apply  and  should  be  considered  a  part  of  Product 
Definition  Data 

After  Release,  formal  procedures  and  documentation  are  required  to  alter  Configuration 
Documents  ( at  least  for  the  'as-designed*).  There  usually  is  a  sequence  of  a  Request  for  Change 
which.  If  approved,  results  in  some  sort  of  Change  Directive.  The  Change  Directive  results  in 
specific  revisions  of  one  or  more  Configuration  Documents  and  represents  those  revisions  until 
such  time  as  the  directed  changes  are  incorporated  into  the  contents  of  the  Configuration 
Documents.  These  Change  Directives  are  part  of  Product  Definition 

During  the  course  of  manufacturing.  Items  come  into  being  which  do  not  conform  to  the 
characterictics  within  the  limits  prescribed  by  the  Configuration  Documents.  Some  of  those 
non-conforming  Items  are  found  acceptable  for  use  'as-is'.  The  *as-built'  configuration 
documentation  seems  then  to  consist  of  the  *as-designed*  plus  differences  introduced  in 
'aa-planned*  plus  the  documentation  of  items  having  acceptable  variances  from  the  prescribed 
limits. 
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With  Figure  3  we  now  have  a  model  of  a  central  structure  fx  Product  Definition  Data.  Other 
Product  Definition  Data  probably  has  direct  x  indirect  relationships  to  entities  in  this  central 
structure. 

The  ‘as-designed*  end  ‘as-plenned*  Items  are  actually  ‘logical  Items*.  That  is,  the  Item 
Identification  represents  the  set  of  chxactxistics  which  a  Physical  Item  should  have  whenever 
it  actually  is  fabricated.  When  we  move  to  the  data  about  ‘as-built*  we  are  now  trying  to  keep 
track  of  what  is  known  about  Physical  items.  This  is  not  hard  if  each  Physical  item  has  a  unique 
identifix  which  distinguishes  it  from  its  siblings  such  as  a  axial  numbx.  We  do  not  axialize 
most  Items.  Instead  we  fabricate  them  in  bunches,  or  mxufacturing  lots,  and  it  is  the  group  that 
fit  we  keep  data  about  and  what  we  know  is  mostly  statistics  about  groups  of  items.  It  will  take  a 

little  wxk  and  considerable  thought  to  produce  a  logical  data  model  in  this  area  which  will 
satisfy  the  rules  fx  such  models. 

!  ho/e  constructed  a  model  which  may  provide  the  core  data  relationships  upon  which  we  can 
construct  the  relationships  of  the  othx  Product  Oefinitix  Data  What  othx  data??  Well ,  hxe 
is  where  you  have  to  stxt  thinking. 

I  will  finish  by  pointing  out  that  the  models  I  have  included  are  what  we  call  Data  Planning 
models.  They  have  xly  bex  developed  to  indicate  basic  relationships  and  xtities.  They  are 
key-based.  That  is,  the  xtities  have  bex  testx  fx  validity  by  establishing  that  they  do  have 
keys  and  the  keys  have  bex  migrated  through  relationships  as  required  by  the  methodology. 
Howevx ,  these  models  are  still  quite  abstract  Diving  attributes  to  the  xtttin  and  applying  the 
rulx  to  attributes  will  cause  the  models  to  grow  additional  xtities,  pxhaps  by  a  factx  of  three 
to  five. 

Anyone  wiXing  to  discuss  these  ideas  may  call  me  at  the  phone  numbx  below  x  write  to  the 
listed  address  and  I  will  try  to  respond 


D.  Appletx  Company,  Inc. 

1 1 04  Highland  Ave. ,  Suite  I 
Mxhattx  Beech,  CA  90266 
(213) 318-2451 
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THE  OOCUnENT  PROBLEH 
IN 

PRODUCT  DATA  nODELINB 

There  ere  two  major  forces  at  work  driving  most  efforts  to  model  Product  Definition  Data.  One 
of  these  is  the  "Paperless  System";  the  idee  that  we  should  be  able  to  eliminate  the  need  for 
paper  copies  and  use  eisrtronic  copies  of  data  instead.  Many  of  the  people  talking  about 
'paperless"  environments  r.ave  not  given  a  great  deal  of  thought  to  what  that  might  mean.  Many 
of  them  in  their  minds  set  images  of  familiar  dxuments  on  a  CRT  or  other  electronic  display 
device.  The  more  advanced  thinkers  see  only  that  data  needed  to  answer  a  particular  question 
rather  than  the  complete  -entente  of  one  of  today’s  dxuments. 

The  second  force  is  Cofreuter  Integrated  Manufacturing  (CIM).  Here  the  visions  are  of 
automated  systems  translr 'ng  designs  into  manufactured  articles  with  very  little  or  no  human 
intervention  To  accomp'-sh  this  end.  we  will  either  have  to  give  the  automated  system  the 
perception,  intuition  and  reasoning  powers  that  people  have,  or  alter  the  way  the  data  is 
presented  and  combined  to  define  the  product  so  that  it  can  be  interpreted  xrrretly  by 
computers. 

When  we  are  working  on  t-r  Product  Definition  Data  Model  we  keep  bumping  against  the  issue  of 
"documents".  In  one  sense  documents  are  external  views  of  deta  In  another  sense,  many  of  the 
dxuments  are  conc^tual  c  ■  •  ;ties. 

As  an  example,  take  "Drawing"  Drawing  seems  to  pass  the  tests  as  a  conceptual  entity  because 
it  is  a  thing,  it  is  a  thing  that  the  enterprise  keeps  date  about  (schedules,  rompletions, 
releases,  revisions,  etc.)  end  exh  instance  has  e  unique  identifier.  A  drawing  is  an  aggregator 
of  requirements  (charxteristics}  for  items.  The  manufacturing  enterprise  has  developed 
significant  business  systems  to  utilize  the  drawing  as  the  means  of  managing  some  of  the 
physical  and  functional  characteristics  of  its  products.  Other  documents,  such  as  specifications, 
are  used  to  manage  other  characteristics. 

When  a  team  starts  modeling  product  definition  data,  they  soon  reach"  drawing"  When  we  try  to 
factor  the  drawing  into  its  data  elements,  we  find  a  variety  of  data  and  information  There  ere 
such  elements  as  a  drawing  number  and  title.  There  are  general  notes  stating  requirements  in  a 
narrative  form.  There  are  one  x  mxe  "views’  of  the  shape  definition.  There  may  be  various 
kinds  of  annotation  essxiated  with  elements  of  the  shape  definition.  There  may  be  a  bill  of 
materials  listing  items  which  are  constituents  of  the  item  being  depicted  by  the  drawing. 

The  lOES  specification  provides  fx  a  drawing,  drawing  views,  flag  notes  and  general  notes  as 
entities  and  that  thinking  cxries  over  into  the  PDES  initiatix  thinking. 

The  PDES  Logical  Layx  committee  has  found  the  "Drawing"  and  is  developing  data  models  related 
to  presentation  of  "views".  There  have  been  discussions  as  to  whethx  x  not  the  "presentation" 
is  a  legitimate  part  of  a  conceptual  scheme  or  is  it  not  a  user  view  x  extxnal  schema  in  the 
sense  of  the  ANSI/X3/SPARC  definitions. 
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It  is  probably  the  case  thai  there  are  both  a  conceptual  drawing  which  is  an  aggregation  entity 
for  data  which  defines  iter  characteristics  and  a  drawing  presentation  which  is  a  user  view  of 
the  drawing  data  We  hav?  a  hard  time  accepting  these  as  different  and  separating  one  from  the 
other. 

In  order  to  achieve  on  understanding  of  a  TO-BE ,  conceptual  drawing,  we  need  to  set  some  sort  of 
discriminator  in  place  in  ;jr  minds.  Currently.  I  find  it  useful  to  ask  myself  if  the  conceptual 
data  mode!  has  a  simple  "ysical  implementation  which  could  be  computer  interpreted.  This 
leads  to  realization  that '  c'  awings"  of  the  future  are  likely  to  be  different  from  those  of  today  in 
more  ways  than  just  beinc  -r  digital  format. 

For  example,  "everbody"  ^  'ows  that  drawings  have  general  notes.  I  can  model  the  statement  that 
a  drawing  has  zero,  one  c  many  general  notes  That  is  small  use  to  the  developer  of  automated 
planning  systems  when  wh;’  a  general  note  soys  is.  "faces  marked  P  shall  be  cadmium  plated  per 
00-P-XXX,  type  11,  class  3  and  shall  be  painted  with  paint  conforming  to  Ml L-P-NNNN,  color 
number  276,  except  that  c'-osshatched  areas  shall  be  plated  but  not  painted” 

With  the  present  state  of  “-e  art  we  are  going  to  have  to  have  a  person  interpret  Ihgt  note  if  we 
ore  going  to  plan  the  produ'  on  of  the  part. 

In  order  to  make  "drawing  interpretable  by  computer .  we  are  probably  going  to  have  to  mrte 
our  elecj^^onic  drawing  sc  oat  associations  such  as  those  betYi«n  surfaces  and  their  required 
finishes  JTClearly  understandable  to  the  automated  planning  system.  This  is  going  to  require 
some  cultural  change  in  the  enterprise  In  the  Defense  industry,  the  culture,  standards  and 
specifications  of  the  customer  will  also  have  to  change. 

The  "drawing"  is  only  one  sample  of  the  "document"  problem  How  should  we  attack  that 
problem? 

I  think  that  we  are  unlikely  to  be  able  to  take  the  "giant  step"  to  the  future  where  the  business  is 
managing  the  product  data  as  electronic  data  and  paper  dxuments  have  become  merely  one  of  the 
ways  to  present  the  data.  That  is  particularly  true  when  we  consider  that  we  ere  evolving  from 
paper  documents  to  electronic  data.  Some  of  each  will  continue  to  exist  for  some  time  to  come. 

In  the  beginning  we  will  probably  have  to  treat  the  paper  documents  os  business  entities  Fx 
such  entities,  our  conceptual  model  will  be  of  the  data  the  business  relates  to  the  documents. 
This  data  is  much  like  the  data  found  in  a  library  card  catalog  about  the  library  collection.  There 
is  the  date  required  to  select  the  document  appropriate  to  the  need  and  data  about  the  location 
where  the  document  can  be  founl  As  we  apply  automation  to  the  generation  of  Product 
Definition,  we  will  begin  by  treating  the  resulting  data  collections  as  electronic  documents  and 
maintain  and  model  the  data  in  much  the  same  manner  as  for  the  paper  documents. 
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Oradually,  as  we  begin  to  better  understand  what  it  is  that  we  are  doing,  we  may  commence  to 
model  and  manage  the  product  definition  date  in  a  way  that  capitalizes  upon  the  available 
computer  technology.  This  will  require  changing  the  thinking  of  many  people  which  1s  not  a 
trivial  task 

The  PDES  project  ts  grappling  with  the  Conceptual  Schema  of  some  of  the  data  which  is 
traditionally  part  of  the  O'^awing  content.  The  prime  focus  is  on  the  definition  of  an  Item  shape 
This  IS  data  which  has  been  captured  in  Computer  Aided  Design  systems.  There  shape  is 
constructed  from  geometr  -:  elements  such  as  lines,  arcs,  splines,  etc.  POES  is  building  upon 
the  PDDI  work  which  con.  udad  that  in  order  for  computers  to  readily  interpret  the  geometric 
shape  data,  it  is  necessar')  *.0  collect  it  into  topological  entitles  such  as  edges,  vertices,  faces  and 
shells 

Another  look  toward  the  TC  5E  suggests  that  the  Group  Technology  ideas  of  Form  Features  such  as 
holes,  pockets,  slots,  grooves,  etc.  may  also  be  used  to  collect  geometric  elements  and  give  them 
meaning. 

The  original  versions  of  IGES  were  based  upon  the  desire  to  find  an  intermediate  format  for  the 
transfer  of  data  presently  '’rund  in  CAD/CAM  systems.  I  believe  that  the  primary  motivation  of 
PDDI  was  to  find  a  more  e*‘’cient  way  to  do  whet  IGES  did  and  add  some  ability  to  transfer  data 
not  neccessarily  found  in  e^  sting  CAD  systems. 

Neither  of  these  projects  hsi  demonstrated  much  thinking  or  modeling  of  the  relationships  of  the 
data  they  have  modeled  to  other  product'definition  data. 

When  we  examine  the  PDDI  and  PDES  thinking,  we  still  find  that  they  tend  to  model  dxuments 
and  Include  presentation  elements  In  their  conceptual  xhemata.  For  example,  they  provide  for 
"color  "  attributes  which  have  no  bearing  upon  the  meaning  of  the  data  The  "views"  found  in  a 
drawing  tend  to  appear  ns  proposed  conceptual  entities.  If  there  Is  a  three-dimensional  model  of 
the  shape  of  an  item ,  views  are  not  required  to  define  the  item  Views  are  then  a  projection  of 
the  three-dimensional  shape  onto  a  two-dimensional  surface  for  presentation  to  people. 

Another  problem  encountered  when  we  are  trying  to  model  dKuments  rather  than  data  Is  that  a 
particular  kind  of  document  may  have  come  to  be  used  for  many  different  purposes  In  wi 
enterprise.  For  example,  in  one  enterprise,  an  Engineering  Order  (EO)  Is  a  document.  It  is 
used  to  record  the  release  of  up  to  ten  drawings.  It  Is  also  used  as  the  formal  release  of  changes 
to  the  content  of  a  drawing  prior  to  incorporation  of  the  changes  in  a  new  version  of  the  drawing. 
It  is  used  as  a  ‘stop  order"  to  halt  fabrication  or  prxurement  of  parts.  Occasionally  the  EO  is 
even  used  as  a  request  to  purchase  parts. 
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When  we  try  to  model  something  like  this  EO  we  usually  decide  that  these  different  things 
documented  on  an  EO  are  actually  different  categories  of  the  EO.  When  we  are  working  on  a 
conceptual  xhema  withc-t  the  handcuffs  of  documents  we  are  more  likely  to  model  an 
“engineering  release",  a  rianufacturlng  stop",  a  "procurement  stop",  a  "change  order"  and  a 
“purchase  order  request"  as  separate  and  distinct  business  entities 
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I  hod  0  number  of  conversotiono  in  Knoxville  representing  some  disquiet  obout  the  Steering 
Committee  policy  statements  about  the  relationship  between  PDES  and  ICES.  As  a  result  I  wrote 
the  attached  memo. 

!  am  sending  an  Info  copy  to  everyone  1  can  remember  having  sxh  conversations  with  so  that 
you  can  see  my  thinking  written  down. 

1  would  appreciate  your  views  on  what !  have  said. 


RogeitfW  C-s'5 
I”*"?  0  App  e’cr  Co  ,  -nc 
1 104  High -and  Ave. 
Manhattan  ?eQch,  CA  9C266 

I ;-3 i 0-245 i 


Phone:  2 


October  21.1 985 


Tc:  ICES  Chairman  and  the  PDES  Proiect  Manager 

From  KiDger  W  Gale 

Subject.  Steering  Committee  Policy  Statement  that  PDES  Version  1.0  Shall  Have  the  Same 
Functionality  as  the  Then  Current  IGES  Version 

The  Steering  Committee  has  issued  a  oolicy  statement  that  version  1.0  of  PDES  shall  have  the 
same  functionality  as  the  then  current  version  of  IGES.  The  problem  is  the  definition  of 
"functionality"  If  it  fs  taken  to  mean,  "the  ability  to  transfer  application  data  founo  m 
computer  graphics  files" ,  then  i  contend  that  we  do  not  know  what  the  “functionality”  of  an  IGES 
file  is  because  there  is  no  knowledge  of  the  meanings  of  the  entities  contained  in  a  file.  Another 
way  of  stating  this  is,  "we  do  not  know  the  uses  to  which  the  IGES  Entities  nave  been  put"'  The 
reason  that  the  meanings  are  not  known  is  that  IGES  is  essentially  a  "one  schema"  device.  It  nas 
been  developed  onmarily  as  a  transform  from  one  internal  lohema,  a  source  CAD  system,  to 
another ,  me  IGES  transfer  file 

Some  aopl’cation  committees  tiave  attempted  to  inject  some  meaning  through  defined  prooerties 
such  as  the  Electrical  Committe  witn  the  "Layer  Property"  to  indicate  that  certain  elements 
-ep'-esent  ctrc:.’*"'/  on  specific  layers  of  a  multi-layer  prm‘ed  circuit  board.  However, 
w'tnout  the  use  of  a  Conceotual  Scnema.  these  will  remar'  islanos  of  meaning  witnout 


The  oniv  wav  'n  wmcn  eoua’  functional  nv  couic  be  estaoiished  v.  jid  be  to  develop  a  Conceptual 
Schema  ccvenrg  the  3C:''C2ti:r  usages  and  estaoi'sh  mardato'v  -.aopihgs  to  specific  e'emerts 
rf  an  iGES  file  ’’his  woulo  rpsulT,  effertiveiy  m  converging  lOt  *  ana  PDES  i  Peiievp  rhar  me 
result  would  neccessitate  the  production  of  an  IGES  file  wnich  A.ju’.u  crouablv  not  meet  the 
corsspt  of  "upward  compatibilih/"  because  it  wcu’d  remove  'o*’c''s  al^eatJy'  permitted  tc 
cx'it’ng  'molsmentations.  it  would  also  demand  introcucticn  of  x-ow-foge  tc  me  ore-ornceesor 
which  r.c*.  now  a  part  of  implementations  Ur.  example  wcul:  oe  ar.  application  layering 
scheme  "cn  ;  Csmontervisiop  usage). 


'or  example,  in  one  enterprise  performing  the  desigr  of  mecha'':al  parts,  mere  m’ght  oe  a 
scheme  that  laver  10  of  me  i>D  system  ‘iie  is  reservec  r-  rienenTt  wmcn  n-crerer’ 
construction  lines  used  as  references  for  the  construction  of  the  orometric  model  of  a  part  i,n 
another  enterprise,  the  choice  might  be  for  layer  20  to  carry  the  same  ■n^:rm.2t’o''  ^  ”  t'^at 's 
known  in  the  oorresocnding  -gES  files  would  oe  mat  there  are  entities  wnicn  nave  a  leve' 
association  There  is  no  know  leoge  that  the  geometry  on  level  1 C  m  ;ne  case,  an:  'eve:  I :  t.  the 
other,  IS  '>0*  pa^'t  of  tu  dei''’ni‘’on  of  the  snaoe  and  size  of  the  pa'",  m  'GE':  ,  m's  sc'"  o' 

meaning  must  be  transmitted  from  ins  senoer  of  the  iGE5  file  to  ■'■e  '■ece'ver  ov  memo  or  some 
ot"er  means  pef'''*?  the  "i’e  oar  pe  oc’‘''ectiy  'r.terpretec  ov  ‘he  '‘ec:’'-'?'' 
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It  IS  true  that  today,  different  CAD  systems  have  different  devices  for  capturing  user-defined 
meanings.  What  is  designated  by  assignment  of  CAD  entities  to  a  layer  in  one  system  may  be 
accomplished  with  the  use  of  a  user-defined  property  in  another  There  is  reason  to  believe 
that,  for  PDE3,  there  may  not  be  a  simple  map  from  a  CAD  system  "layer”  to  a  “lever  as  there 
is  now  in  IGES.  When  the  data  meanings  are  understood  through  the  use  of  a  Conceptual  Schema, 
the  "level"  mey  not  be  found  to  be  an  aporopnate  device  for  such  a  meaning. 

Phil  Kenr.icott  keeps  insisting  to  me  that  there  is  a  conceptual  schema  for  tOES.  I  keep  trying  to 
tell  him  that  I  will  believe  that  when  I  see  it.  By  "see  it”  I  mean  expressed  in  IDEFIX  or  lA 
which  are  the  only  two  languages  I  find  with  a  comprehensible  format  for  expression  of  most  of 
the  content  required  for  a  Conceptual  Schema 

An  !GES  “Level"  or  “Group  Associativity"  is  not  an  IDEFIX  Conceptual  Schema  Entity  or 
Attribute.  It  is  an  Internal  Senema,  physical  file  entity  which  mey  take  on  many  meanings 
depending  upon  the  soura  application,  or  even  individual  user.  If  the  user  "grouped"  some 
geometric  entities  with  the  intent  tnat  they  defined  a  hole,  then  the  transfer  file  should  tell  me 
that  this  is  a  "hole  defining  group"  not  just  a  group  without  a  reason  for  being  grouped. 

I  believe  that  because  POES  is  going  to  be  developed  with  the  three- schema  concept  from  the 
beginning  and  IGES  was  mostly  one- schema  and  at  best  two-schema,  there  is  a  low  probability 
that  there  will  be  unambiguous  mappings  between  them.  Everyone  involved  in  PDES  including 
the  Steering  Committee  needs  to  develop  a  deeper  understanding  the  differences  between  IGES 
anc  PDES  before  making  pronouncements  of  schedules  and  relatior.inips. 

I  am  concerned  that  we  are  about  to  embark  on  PDES  with  a  very  .-•realistic  set  of  expectations, 
net  only  among  ourselves,  but  tc  an  ever  worse  degree  among  "s  non-participants  who  are 
•aireaev  making  noises  about  PDES  bemg  the  integr.3tion  terhnologv  dill 

I  suggest  that  this  is  a  topic  which  ought  to  be  cn  the  Agenda  for  the  'lext  'General  Meetirg  and 
oroDaolv  for  sucseauent  General  Meetings. 
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